|
From: Philippe W. <phi...@sk...> - 2023-01-08 21:56:40
|
On Sun, 2023-01-08 at 22:25 +0100, Mark Wielaard wrote: > 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? Implementing an extension to the protocol will effectively allow GDB to load a file or get the python code to evaluate at connect time. > > 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? IIRC, that was effectively because old GDB versions or GDB compiled without expat/xml support will not work. Another reason is that info reg and company will show a lot more info if we put yes by default. > > Thanks, > > Mark |