|
From: Mark W. <ma...@kl...> - 2023-01-08 21:25:51
|
Hi Philippe, On Sun, Jan 08, 2023 at 09:28:32PM +0100, Philippe Waroquiers wrote: > On Sun, 2023-01-08 at 21:17 +0100, Mark Wielaard wrote: > > > 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. O, I forgot that the install location of the script can differ. Hmmm. Do you think it might make sense to ask for a gdb remote protocol extension? So gdb may ask the remote target for a script to load to extend the functionality of the target? BTW. I wanted to ask you about the --vgdb-shadow-registers=no default. Is this because older GDB versions might not understand this? If so, is there a way to detect a newer GDB/remote protocol version to turn the default to yes? Thanks, Mark |