|
From: Philippe W. <phi...@sk...> - 2023-01-08 20:28:44
|
Hello Mark, Thanks for the feedback, reply below. On Sun, 2023-01-08 at 21:17 +0100, Mark Wielaard wrote: > 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? I just followed the recommendation given in the GDB python documentation. Note that the section must be in an "early" loaded valgrind shared object. > > The asm statement is also added to m_main.c, why is that? This was a leftover of a failed trial to have the python code auto-loaded by GDB before valgrind started its execution. It has been removed in the version that was pushed this afternoon. > > > 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 Effectively, if GDB knows it is speaking with a valgrind gdbserver, then GDB can itself load the python code before valgrind starts its execution. GDB however will have to find the location of this python code, at it depends on the version of valgrind it (will) connect to. > > > 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 |