Bug 510694

Summary:	Handle qExecAndArgs remote protocol packet
Product:	[Developer tools] valgrind	Reporter:	Alexandra Hajkova <ahajkova>
Component:	general	Assignee:	Alexandra Hajkova <ahajkova>
Status:	RESOLVED FIXED
Severity:	normal	CC:	mark
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	patch patch

Description Alexandra Hajkova 2025-10-16 19:50:03 UTC

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.

Comment 1 Alexandra Hajkova 2025-10-22 10:57:40 UTC

Created attachment 186000 [details]
patch

Comment 2 Alexandra Hajkova 2025-10-22 10:59:03 UTC

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".

Comment 3 Alexandra Hajkova 2025-10-22 13:30:16 UTC

Created attachment 186003 [details]
patch

v2: - use handle_query.qExecAndArgs in VG_(malloc)

Comment 4 Mark Wielaard 2025-10-24 14:45:48 UTC

(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".