|
From: Mark W. <ma...@kl...> - 2023-01-08 20:17:40
|
Hi Philippe, On Tue, Dec 27, 2022 at 11:11:51PM +0100, Philippe Waroquiers wrote: > 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 see you add it to the vg_preload file with an asm statement. Is that easier than using a linker script? The asm statement is also added to m_main.c, why is that? > 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 Sasha's has been working on adding a --multi option to vgdb. https://bugs.kde.org/show_bug.cgi?id=434057 That way you can start a program under valgrind from gdb. The idea was that we would use this to have a special kind of target valgrind in gdb which can/should setup a couple of things for the user to make the gdb/valgrind integration a bit smoother. Such a "target valgrind" could then also automatically load valgrind-monitor.py > 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) > > or: > (gdb) p some_mem > $4 = "\000\000\000\000" > (gdb) memcheck xb &$4 > 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. This is so useful! Thanks for working on this. Cheers, Mark |