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.
Add abexit in --vgdb-stopat. fix 459031 --error-exitcode doc. Add lwpid in thread_wrapper tracing.
Note that this modifies files on darwin/solaris/bsd but I only did a linux
build so possibly this commit might cause a compilation error, that should
then be trivial to fix.
Also added memmem test in the list of ignored files.
Mark Wielaard [Mon, 29 Aug 2022 08:10:27 +0000 (10:10 +0200)]
Replace git:// URLs with https:// URLs
For unauthenticated git clones it is slightly more secure to use the https
link because the site certificate will be checked. Also https might be more
accessible from all places than the git protocol port.
Andreas Arnez [Thu, 19 May 2022 11:54:06 +0000 (13:54 +0200)]
Bug 454040 - Add intercept for memmem on s390x
Memcheck may report false positives in an optimized version of memmem on
s390x, specifically on arch13 systems. Prevent this by adding an
intercept for memmem on s390x platforms.
Paul Floyd [Sun, 3 Jul 2022 11:05:54 +0000 (13:05 +0200)]
Bug-456171 [PATCH] FreeBSD: Don't record address errors when accessing the 'kern.ps_strings' sysctl struct
There is quite a lot of stuff here.
The problem is that setproctitle and kern.ps_strings were using the Valgrind host auxv
rather than the guest. The proposed patch would have just ignored those memory ranges.
I've gone a fair bit further than that
1. refactored the initimg code for building the client auxv. Previously we were
simply ignoring any non-scalar entries. Now we copy most of thse as well.
That means that 'strtab' built on the client stack no longet only contains
strings, at can also now contain binary structures. Note I was a bit
concerned that there may be some alignment issues, but I haven't seen any
problems so far.
2. Added intercepts to sysctl and sysctlbyname for kern.ps_strings, then find
AT_PS_STRINGS from the client auxv that is now usable from step 1.
3. Some refactoring of sysctl and sysctlbyname syscall wrappers. More to do
there!
4. Added a setproctitle testcase (that also tests the sysctls).
5. Updated the auxv testcase now that more AT_* entries are handled.
Paul Floyd [Sat, 18 Jun 2022 06:59:08 +0000 (08:59 +0200)]
Add some FreeBSD Helgrind suppressions
These are mainly for debug builds of libthr.so for which
1. the lib name will be libthr.so.3.full
2. callstacks change because of inlining
3. more symbols are available
Paul Floyd [Fri, 17 Jun 2022 11:52:45 +0000 (13:52 +0200)]
Fix a few issues with reallocf and add a FreeBSD amd64 regtest
1. new_size is size_t (unsigned) and can't be negative
2. NULL not returned when the size is 0 and the memory freed
3. set ENOMEM if the allocation fails (but this time NULL does
get returned)
Paul Floyd [Tue, 14 Jun 2022 20:39:31 +0000 (22:39 +0200)]
Implement vgdb invoker on FreeBSD
This is a translation of the Linux vgdb-invoker-ptrace.c
to the FreeBSD ptrace dialect. It seems to be basically
functional (3 out of 4 of the regression tests pass,
and for the 4th one it seems to be a limitation of
ptrace on FreeBSD that it can cause syscalls to be
interrupted).
read dwarf5 DW_FORM_addrx* and DW_FORM_strx* as generated by Clang14
DW_FORM_addrx* are offsets into .debug_addr containing addresses.
DW_FORM_strx* are offsets into .debug_str_offsets, which contain
offsets into .debug_str. Support for these also requires reading
DW_AT_addr_base and DW_AT_str_offsets_base before any other field
in the abbrev table entry, as those may use this form.
Mark Wielaard [Thu, 9 Jun 2022 21:06:36 +0000 (23:06 +0200)]
syswrap-linux.c (sys_execveat): Define path as const HChar *
Like buf, path (ARG2) is a const HChar *
Prevents a gcc warning: assignment discards 'const' qualifier from
pointer target type [-Wdiscarded-qualifiers]
13328 | path = buf;
| ^
Many changes mostly related to modifying VG_(di_notify_mmap)( Addr a, Bool allow_SkFileV, Int use_fd )
so that instead of triggering debuginfo reading after seeing one RX PT_LOAD and 1 RW PT_LOAD it
can handle either 1 or 2 RW PT_LOADs.
Paul Floyd [Mon, 6 Jun 2022 13:18:29 +0000 (15:18 +0200)]
Use a different way to tell where the syscall handler was interrupted on FreeBSD and macOS
I was using a global variable. This would be set to '1' just before
calling the function to save cflags and cleared just after, then
using the variable to fill in the 'outside_rnage_ condition
in VG_(fixup_guest_state_after_syscall_interrupted)
Even though I haven't experienced any isseus with that, the comments just before
do_syscall_for_client made me want to try an alternative.
This code is very ugly and won't please the language lawyers.
Functions aren't guaranteed to have an address and there is no
guarantee that the binary layout will reflect the source layout.
Sadly C doesn't have something like "sizeof(*function)" to give
the size of a function in bytes. The next best that I could
manage was to use dummy 'marker' functions just after the
ones I want the end address of and then use the address of
'marker - 1'
I did think of one other way to do this. That would be to
generate a C file containing the function sizes. This would
require
1. "put_flag_size.c" would depend on the VEX guest_(x86|amd64)_helpers
object files
2. Extract the sizes, for instance
projects / thirdparty / valgrind.git / log
