Re: [PATCH 2/2] gdb: use current executable for 'remote exec-file' in some cases

[Andrew Burgess <aburgess@redhat.com>]

Simon Marchi <simark@simark.ca> writes:

> On 10/11/25 9:34 AM, Andrew Burgess wrote:
>> This commit allows GDB to make use of the file set with the 'file'
>> command when starting a new inferior on an extended-remote target.
>> There are however some restrictions.
>> 
>> If the user has used 'set remote exec-file', then this setting is
>> always used in preference to the file set with the 'file' command.
>> 
>> Similarly, if the qExecAndArgs packet has succeeded, and GDB knows
>> that the remote target has an executable set, then this will be used
>> in preference to the file set with the 'file' command; this preserves
>> GDB's existing behaviour.  In effect, when GDB connects to the remote
>> target, the remote sets the 'remote exec-file' and this prevents GDB
>> from using the 'file' filename.
>> 
>> And, GDB can only use the file set with the 'file' command if it
>> believes that both GDB and the remote target will both be able to
>> access this file.  This means that one of these is true:
>> 
>>   + the the remote_target::filesystem_is_local function returns
>>     true (see the implementation of that function for details of when
>>     this can happen).  This means GDB and the remote target can see
>>     the same file system, GDB can just use the current executable's
>>     filename as is, or
>> 
>>   + the user has set the 'file' to something with a 'target:' prefix,
>>     e.g. 'file target:/path/to/exec'.  In this last case, GDB will use
>>     the exec filename without the 'target:' prefix, this filename is,
>>     by definition, something the remote target can see, or
>> 
>>   + the sysroot has been updated by the user and no longer contains a
>>     'target:' prefix.  In this case, if the 'file' filename is within
>>     the sysroot, then it is assumed the remote will also be able to
>>     see a file with the same filename.  For example, if the sysroot is
>>     '/aa/', and the current executable is '/aa/bb/cc', then GDB will
>>     tell the remote to run '/bb/cc'.  One common case here is when the
>>     sysroot is set to the empty string, which is usually done when GDB
>>     and the remote target can see the same filesystem, in this case
>>     GDB will use the current executable's filename unmodified.
>> 
>> If one of these conditions is met, then GDB will use the current
>> executable's filename (with possible modifications as mentioned
>> above), when starting a new extended-remote inferior, in all other
>> cases, GDB will use the file name  set with 'set remote exec-file'.
>> 
>> This change could be useful any time a user is running a remote target
>> on the same machine as GDB, but I am specifically thinking of the case
>> where GDB is using a tool other than gdbserver, e.g. valgrind, as this
>> saves one additional step that a user must remember.  The current
>> steps to start valgrind with GDB, as given on the valgrind
>> website (https://valgrind.org/docs/manual/manual-core-adv.html) are:
>> 
>>   $ gdb prog
>>   (gdb) set remote exec-file prog
>>   (gdb) set sysroot /
>>   (gdb) target extended-remote | vgdb --multi --vargs -q
>>   (gdb) start
>> 
>> With this GDB work, and once support for the qExecAndArgs packet is
>> added to valgrind, then the 'set remote exec-file' line can be dropped
>> from those instructions.
>> 
>> This commit also extends the 'show remote exec-file' command so that
>> GDB will display the automatic value that it plans to use.  Here's an
>> example of the new output:
>> 
>>   $ gdb -q /tmp/hello
>>   Reading symbols from /tmp/hello...
>>   (gdb) set sysroot
>>   (gdb) target extended-remote | ./gdbserver/gdbserver --multi --once -
>>   Remote debugging using | ./gdbserver/gdbserver --multi --once -
>>   Remote debugging using stdio
>>   (gdb) show remote exec-file
>>   The remote exec-file is unset, using automatic value "/tmp/hello".
>> 
>> The last line shows the new output.
>> 
>> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
>
> I am investigating a regression when running gdb.gdb/selftest.exp with
> the native-extended-gdbserver board, caused by my commit d6340aa42e25
> ("gdb/testsuite: use libtool to launch selftests").  A side-effect of my
> change is that the test no longer does a "set remote exec-file", which
> is currently required in order to run a new process with an
> extended-remote board.  I started writing a patch to add a manual "set
> remote exec-file", but then remembered about this patch.  I gave it a
> try, and indeed it fixes those regressions.  I would therefore be very
> happy to see this patch merged (I had forgotten about it before just now
> to be honest).
>
> I'm fine with what you have see below for small comments.
>
> Approved-By: Simon Marchi <simon.marchi@efficios.com>
>

I addressed the nits you pointed out, and pushed this patch.

Thanks,
Andrew