If valgrind is started like this: valgrind --tool=memcheck --vgdb=full --vgdb-stop-at=startup /path/to/prog arg1 arg2 arg3 then valgrind will start up, and prompt us to connect to the running process like this: (gdb) gdb /path/to/prog target remote | /usr/bin/vgdb --pid=12345 In this case the remote target is already running. There are a couple of things here which don't really work. The most important is (gdb) show args Argument list to give program being debugged when it is started is "". If the qExecAndArgs were supported then this could potentially show the actual argument list here. The other thing that doesn't work, is: (gdb) show remote exec-file which shows the empty string, with full qExecAndArgs this would show the actual remote executable filename.
Created attachment 186000 [details] patch
New qExecAndArgs packet has been added recently to GDB's remote protocol. The new qExecAndArgs packet is sent from GDB, and gdbserver replies with a packet that includes the executable filename and the arguments string that were used for starting the initial inferior. On the GDB side this information can be used to update GDB's state, the 'show remote exec-file' will reflect how gdbserver was started, and 'show args' will reflect the arguments used for starting the inferior. When running valgrind together with GDB like this: ./vg-in-place --tool=memcheck --vgdb-error=0 /bin/ls -lh ~/build/gdb/gdb/gdb target remote | coregrind/vgdb We can now ask GDB to show the executable's arguments: (gdb) show args Argument list to give program being debugged when it is started is "-lh". or the executable's name: (gdb) show remote exec-file The remote exec-file is "/bin/ls".
Created attachment 186003 [details] patch v2: - use handle_query.qExecAndArgs in VG_(malloc)
(In reply to Alexandra Hajkova from comment #3) > Created attachment 186003 [details] > patch > > v2: - use handle_query.qExecAndArgs in VG_(malloc) Thanks for the update. We discussed and tested on irc. I have pushed this so it gets into v3.26.0. It nicely complements the vgdb implementation. But now it also works (with latest gdb trunk) for the traditional target remote. commit f80358f109d1bce25d2013579e5d4b933b502797 Author: Alexandra Hájková <ahajkova@redhat.com> Date: Wed Oct 15 06:27:25 2025 -0400 server.c: handle qExecAndArgs remote protocol packet New qExecAndArgs packet has been added recently to GDB's remote protocol. The new qExecAndArgs packet is sent from GDB, and gdbserver replies with a packet that includes the executable filename and the arguments string that were used for starting the initial inferior. On the GDB side this information can be used to update GDB's state, the 'show remote exec-file' will reflect how gdbserver was started, and 'show args' will reflect the arguments used for starting the inferior. When running valgrind together with GDB like this: ./vg-in-place --tool=memcheck --vgdb-error=0 /bin/ls -lh ~/build/gdb/gdb/gdb target remote | coregrind/vgdb We can now ask GDB to show the executable's arguments: (gdb) show args Argument list to give program being debugged when it is started is "-lh". or the executable's name: (gdb) show remote exec-file The remote exec-file is "/bin/ls".