Paul Floyd [Sat, 21 Jan 2023 19:46:24 +0000 (20:46 +0100)]
FreeBSD: Fix auxv AT_EXECPATH
This was being copied from the host. Now it's synthesized for
the guest. Also improve the none/freebsd/auxv test to
print a few of the strings in auxv (but not the envp ones).
Paul Floyd [Sat, 21 Jan 2023 16:55:09 +0000 (17:55 +0100)]
Bug 464476 - Firefox fails to start under Valgrind
On FreeBSD, Firefox uses the kern.proc.pathname.PID sysctl
to get the binary path (where PID can be the actual pid
or -1). The user path is /usr/local/bin/firefox which is
a symlink to /usr/local/lib/firefox/firefox.
This was failing because we were not handling this MIB.
That meant that the sysctl returned the path for the
binary of the running tool (e.g.,
/home/paulf/scratch/valgrind/memcheck/memcheck-amd64-freebsd).
Firefox looks for files in the same directory.
Since it was the wrong directory it failed to find them and
exited.
I also noticed a lot of _umtx_op errors. On analysis they
are spurious. The wake ops take an "obj" argument, a pointer
to a variable. They only use the address as a key for
lookups and don't read the contents.
Mark Wielaard [Sun, 15 Jan 2023 13:24:19 +0000 (14:24 +0100)]
m_debuginfo: Suppress warning about not handling entry_value ops
The warning: evaluate_Dwarf3_Expr: unhandled DW_OP_ 0xf3 isn't
very helpful. This means we didn't handle DW_OP_GNU_entry_value.
DW_OP_GNU_entry_value (or DWARF5 DW_OP_entry_value) means interpreting
the given DWARF expression using register values as they were upon
entering the function. Which is non-trivial to implement.
We can fail the evaluation of the DWARF expression without warning
about it by default, since it isn't really needed for any current
valgrind functionality (and it is only done with --read-var-info=yes.
Andreas Arnez [Wed, 26 Oct 2022 17:45:30 +0000 (19:45 +0200)]
s390: Add test for short/extended vector float insns
Several issues with vector floating point instructions have gone unnoticed
due to a lack of test coverage in this area. Add a test case that
improves the coverage, particuarly when dealing with short and extended
floating point formats.
Andreas Arnez [Wed, 30 Nov 2022 18:15:53 +0000 (19:15 +0100)]
s390: Fix VFMA, VFMS, VFNMA, and VFNMS for 128-bit FP
When trying to execute any of the vector float multiply-and-add family
instructions, Valgrind panics with the message "Iex_Qop with F128 data".
So far all F128 operations were implemented with instructions that operate
on FP register pairs. However, such instructions don't exist for
Iop_MAddF128 and Iop_MSubF128, so they must be implemented with vector
instructions instead. This was missed when emitting them in
"guest_s390_toIR.c".
Add the missing support. This also involves adding a few new features to
host_s390_defs:
* a new vector operation S390_VEC_INIT_FROM_FPRS
* the capability to move the left half of a VR to an FPR
Implement front end GDB commands for Valgrind gdbserver monitor commands.
This commit implements in python a set of GDB commands corresponding to the
Valgrind gdbserver monitor commands.
Basically, the idea is that one GDB command is defined for each valgrind
gdbserver subcommand and will generate and send a monitor command to valgrind.
The python code is auto-loaded by GDB as soon as GDB observes that the valgrind
preload core shared lib is loaded (e.g. vgpreload_core-amd64-linux.so).
This automatic loading is done thanks to the .debug_gdb_scripts section
added in vg_preloaded.c file.
Sadly, the auto-load only happens once valgrind has started to execute the code
of ld that loads this vg_preload file.
I have tried 2 approaches to have the python code auto-loaded when attaching at
startup to valgrind:
* have valgrind gdbserver reporting first to GDB that the executable file is
the tool executable (with a .debug_gdb_scripts section) and then reporting
the real (guest) executable file.
The drawback of this approach is that it triggers a warning/question in GDB
according to the GDB setting 'set exec-file-mismatch'.
* have valgrind gdbserver pretending to be multiprocess enabled, and report
a fake process using the tool executable with a .debug_gdb_scripts section.
The drawback of this is that this always creates a second inferior in GDB,
which will be confusing.
Possibly, we might complete the below message :
==2984378== (action at startup) vgdb me ...
==2984378==
==2984378== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==2984378== /path/to/gdb /home/philippe/valgrind/littleprogs/some_mem
==2984378== and then give GDB the following command
==2984378== target remote | /home/philippe/valgrind/git/improve/Inst/libexec/valgrind/../../bin/vgdb --pid=2984378
==2984378== --pid is optional if only one valgrind process is running
with:
==2984378== GDB valgrind python specific commands will be auto-loaded when execution begins.
==2984378== Alternatively, you might load it before with the GDB command:
==2984378== source /abs/path/to/valgrind/install/libexec/valgrind/valgrind-monitor.py
The following GDB setting traces the monitor commands sent by a GDB valgrind
command to the valgrind gdbserver:
set debug valgrind-execute-monitor on
How to use the new GDB valgrind commands?
-----------------------------------------
The usage of the GDB front end commands is compatible with the
monitor command as accepted today by Valgrind.
For example, the memcheck monitor command "xb' has the following usage:
xb <addr> [<len>]
With some piece of code:
'char some_mem [5];'
xb can be used the following way:
(gdb) print &some_mem
(gdb) $2 = (char (*)[5]) 0x1ffefffe8b
(gdb) monitor xb 0x1ffefffe8b 5
ff ff ff ff ff
0x4A43040: 0x00 0x00 0x00 0x00 0x00
(gdb)
The same action can be done with the new GDB 'memcheck xb' command:
(gdb) memcheck xb 0x1ffefffe8b 5
ff ff ff ff ff
0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00
(gdb)
At this point, you might ask yourself: "what is the interest ?".
Using GDB valgrind commands provides several advantages compared to
the valgrind gdbserver monitor commands.
Evaluation of arguments by GDB:
-------------------------------
For relevant arguments, the GDB command will evaluate its arguments using
the usual GDB evaluation logic, for example, instead of printing/copying
the address and size of 'some_mem', the following will work:
(gdb) memcheck xb &some_mem sizeof(some_mem)
ff ff ff ff ff
0x1FFEFFFE8B: 0x00 0x00 0x00 0x00 0x00
(gdb)
This is both easier to use interactively and easier to use in GDB scripts,
as you can directly use variable names in the GDB valgrind commands.
Command completion by GDB:
--------------------------
The usual command completion in GDB will work for the GDB valgrind commands.
For example, typing TAB after the letter 'l' in:
(gdb) valgrind v.info l
will show the 2 "valgrind v.info" subcommands:
last_error location
(gdb) valgrind v.info l
Note that as usual, GDB will recognise a command as soon as it is unambiguous.
Usual help and apropos support by GDB:
--------------------------------------
The Valgrind gdbserver provides an online help using:
(gdb) monitor help
However, this gives the help for all monitor commands, and is not searchable.
GDB provides a better help and documentation search.
For example, the following commands can be used to get various help
or search the GDB Valgrind command online documentation:
help valgrind
help memcheck
help helgrind
help callgrind
help massif
to get help about the general valgrind commands or the tool specific commands.
Examples of searching the online documentation:
apropos valgrind.*location
apropos -v validity
apropos -v leak
User can define aliases for the valgrind commands:
--------------------------------------------------
The following aliases are predefined:
v and vg for valgrind
mc for memcheck
hg for helgrind
cg for callgrind
ms for massif
So, the following will be equivalent:
(gdb) valgrind v.info location &some_mem
(gdb) v v.i lo &some_mem
(gdb) alias Vl = valgrind v.info location
(gdb) Vl &some_mem
Thanks to Hassan El Karouni for the help in factorising the python
code common to all valgrind python commands using a decorator.
Avoid doing mempool specific leak search activities if there are no mempools
For most memcheck users, no mempools are used, but the leak search logic
was doing in any case special handling, leading to useless work such as
sorting again an already sorted array and making a copy of an array without
modifying it.
Julian Seward [Wed, 4 Jan 2023 16:12:21 +0000 (17:12 +0100)]
Fix 64-bit uncleanness in VG_(get_bbs_translated)/VG_(get_bbs_discarded_or_dumped) ..
.. and some debug printing associated with them. I don't think this affects
anything apart from debug printing. Noticed when running a x86 (32-bit)
Firefox build.
Julian Seward [Wed, 4 Jan 2023 16:04:03 +0000 (17:04 +0100)]
amd64 and x86 front ends: add a few more spec rules.
amd64:
S and NS after LOGICQ (per comments from Eyal Soha on the dev list)
S after SHLQ
NZ after SHLL
x86:
NZ after SHRL
Z after SHLL
I would have liked to have added the inverse conditions in all cases (eg, both
S and NS, or both Z and NZ), but finding use cases for some of these is almost
impossible, hence they are sometimes omitted. All of the added cases have
been tested.
Julian Seward [Wed, 4 Jan 2023 15:32:03 +0000 (16:32 +0100)]
Memcheck: handle origin data for 8-/16-bit shadow stores a bit more accurately.
With origin tracking enabled, 8- and 16-bit stores could sometimes lose origin
info unnecessarily. This patch removes this avoidable lossage. (Since MC
only stores 1 origin value for each 32-bit word of address space, there is
still unavoidable lossage of origins in some cases; this patch does not help
in those cases since it's a fundamental design limitation.)
Extend hg04_race to have more entries in the conflicting stacktrace,
and make another test hg04_race_h9 to test with one more entry than
the default of 8.
Add clo option the nr of entries in helgrind --history-level=full stack traces
The number of such entries was hardcoded to 8.
A new command line option -history-backtrace-size=number allows
to set the (max) number of entries to record.
Pass a dummy process_option_state for dynamic options
The process_option_state is functionally needed during initial parsing
of CLO options. When later changing them, only changing the CLO
itself is good enough.
But the processing of option needs to have a state.
The compiler reported a duplicated condition in VEX/priv/guest_ppc_toIR.c
The handling of the plbz and xxpermx instructions have the same if/elseif
conditions. The else if condition for the plbz instruction was wrong. The
elseif statement should be checking for pType2 not pType1. The plbz
instruction was inadvertently being handled by the else statement for
the lbz instruction.
This patch fixes the checking for the plbz and lbz instructions.
Paul Floyd [Sun, 23 Oct 2022 13:16:51 +0000 (15:16 +0200)]
Fix DRD and Helgrind on Solaris.
It seems as though Solaris RW sections can also have the
execute flag set. Checking for RW and !X was causing the
debuginfo reading to fail. That meant that the helgrind and
drd preload shared libraries weren't processed, and also
the rtld bind function pointers not setup. Without the rtld bind
function an assert fires and Helgrind and DRD abort.
Both a.c and cgout-test are checked into the repository and
used in testcases. Make sure cgout-test is newer than a.c
before running the post script to prevent warnings liks:
@@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@ WARNING @@
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ Source file 'a.c' is more recent than input file
../../cachegrind/tests/cgout-test'.
@ Annotations may not be correct.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Paul Floyd [Thu, 20 Oct 2022 21:11:42 +0000 (23:11 +0200)]
Fix build on macOS
A while back when I added support for split RW PT_LOAD sections
one instance in the macho code didn't get updated. Also
update the comment that refers to the old struct member that
got renamed.
Paul Floyd [Tue, 18 Oct 2022 21:38:36 +0000 (23:38 +0200)]
Add auxv entry for usrstack on FreeBSD 14, part 1
Previously the user stack was obtained using the kern.usrstack
sysctl. This has been moved to auxv in FreeBSD 14. Without
this change all programs linked with libthr fail with a panic
when they fail to get a valid user stack address.
Note also in FreeBSD 14 ASLR has been enabled. This means that
there is now some extra difference between the address layout of
a standalone executable and the same executable under valgrind.
Pre-FreeBSD 14 and under valgrind:
lib rtld is loaded after the executable (though a much smaller gap
inder valgrind)
user stack starts at 0x7ffffffff000
FreeBSD 14
lib rtld is loaded at a much higher address, around 0xeeeecc15000
user stack is at a much lower address, around 0x82073d000
This means that valgrind behaves somewhat as thogh the
kern.elf(64|32).aslr.stack sysctl were set to 0.
Some more work will be needed for the stack size.
There are no plans at the moment to match the FreeBSD 14 memory
layout.
The valgrind gdbserver inheritated a register cache from the original
GDBserver implementation.
The objective of this register cache was to improve the performance
of GDB-> gdbserver -> inferior by avoiding the gdbserver having to
do ptrace system calls each time GDB wants to read or write a register
when the inferior is stopped.
This register cache is however not useful for the valgrind gdbserver:
As the valgrind gdbserver being co-located with the inferior, it
can directly and efficiently read and write registers from/to the VEX
state.
This commit ensures the valgrind GDBserver directly reads from
VEX state instead of fetching the registers from the VEX state and
copying them to the gdbserver regcache.
Similarly, when GDB wants to modify a register, the valgrind GDB server now
directly writes into the VEX state instead of writing the registers
in the regcache and having the regcache flushed to the VEX state
when execution is resumed.
The files regcache.h and regcache.c are still useful as they provide
a translation between a register number, a register name on one side
and the offset in an array of bytes in the format expected by GDB.
The regcache now is only used to create this array of bytes, which is
itself only used temporarily when GDB reads or writes the complete
set of registers instead of reading/writing one register at a time.
Removing the usage of this regcache avoids the bug 458915.
The regcache was causing the bug in the following circumstances:
We have a thread executing code, while we have a bunch of threads
that are blocked in a syscall.
When a thread is blocked in a syscall, the VEX rax register is set to the
syscall nr.
A thread executing code will check from time to time if GDB tries to
attach.
When GDB attaches to the valgrind gdbserver , the thread executing code
will copy the registers from all the threads to the thread gdbserver regcache.
However, the threads blocked in a system call can be unblocked e.g.
because the epoll_wait timeout expires. In such a case, the thread will
still execute the few instructions that follow the syscall instructions
till the thread is blocked trying to acquire the scheduler lock.
These instructions are extracting the syscall return code from the host
register and copies it to the valgrind VEX state.
However, this assembly code is not aware that there is a gdbserver cache.
When the unblocked thread is on the acquire lock statement,
the GDB server regcache is now inconsistent (i.e. different from) the
real VEX state.
When finally GDB tells GDB server to continue execution, the GDB server
wrongly detected that its regcache was modified compared to the VEX state:
the regcache still contains e.g. for the rax register the syscall number
while the unblocked thread has put the syscall return code in the VEX
rax register. GDBserver then flushed the regcache rax (containing the
syscall number) to the VEX rax.
And that led to the detected bug that the syscall return code seen by
the guest application was the syscall number.
Removing the regcache ensures that GDB directly reads the values
from VEX and directly writes to VEX state.
Note that we could still have GDB reading from VEX a register value
that will be changed a few instructions later.
GDB will then show some (slightly) old/obsolete values
for some registers to the user.
This should have no consequence as long as GDB does not try to modify
the registers to execute an inferior call.
The bug did not happen systematically as most of the time, when threads are
blocked in syscalls, vgdb attaches using ptrace to the valgrind process.
When vgdb attaches with ptrace, it stops all the threads using linux syscall.
When vgdb stops the threads, the threads blocked in a syscall will not
execute the instructions between the syscall instruction and the lock
acquire, and so the problem of desynchronisation between the VEX state
and the register cache could not happen.
This commit touches architecture specific files of the gdbserver,
it has been tested on amd64/debian, on pcc64/centos and on arm64/ubuntu.
Possibly, some untested arch might not compile but the fix should be trivial.
projects / thirdparty / valgrind.git / log
