Re: exec-file-mismatch and native-gdbserver testing

[Pedro Alves <palves@redhat.com>]

On 5/17/20 6:24 AM, Philippe Waroquiers via Gdb wrote:
> On Sat, 2020-05-16 at 21:10 +0100, Pedro Alves via Gdb wrote:
>>
>> So I cooked up something.  Below's the resulting preliminary patch.
>>
>> Seems to work nicely -- it fixes gdb.base/argv0-symlink.exp at least.
>> I haven't run the testsuite yet.
> I have looked at the patch and played a little bit in a native setup.
> It worked as expected, the patch looks ok to me.
> 
> Note that buildid comparison means that the exec-file used by
> GDB might not be the (same physical) exec-file of the process
> being debugged.

Right.  A common use case is for the target to run a stripped
executable, while gdb is loaded with an executable with debug
info.  The build IDs will match in this case, while filenames
most probably won't.

Related, when remote debugging, it's very common that the path on
the remote system is different from the path of the file loaded on
gdb.  Many people doing embedded development will have setups where
the IDE copies a local file to the target for debugging, and
remotely puts the file under $HOME, or under /tmp, just like
that dejagnu does when remote testing.  You can get a sense of that if
you try the testsuite with --target_board=remote-gdbserver-on-localhost:

 (gdb) spawn /usr/bin/ssh -l pedro localhost /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/../../gdbserver/gdbserver --once localhost:2346 break
 Process /home/pedro/break created; pid = 12712
 Listening on port 2346
 target remote localhost:2346
 Remote debugging using localhost:2346
 warning: Mismatch between current exec-file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.base/break/break
 and automatically determined exec-file /home/pedro/break
 exec-file-mismatch handling is currently "ask"
 Load new symbol table from "/home/pedro/break"? (y or n) 

> For some specific scenarios, it might have an impact,
> such as the user wanting to debug a copy of the file to avoid
> 'Text file busy', maybe some interaction with setuid/setgid, ... ?

These seem like rarer scenarios, which would cause warnings/errors
anyway if you pick the wrong executable?

I'm thinking, if we support build ID validation, do we really want
to fallback to filename validation?  It seems to me that it causes
more false positives than desirable.

> 
> Maybe good enough to mention this in the user manual and/or in the
> 'help set exec-file-
> mismatch' ?
> Or maybe GDB should give a message to the user for different files
> but same buildid ?
> 
> 
>>
>> There's (at least) one issue that I'll need to fix.  It's to
>> get rid of the "transfers from remote targets can be slow" warning
>> when we open the remote file to read the build id:
> 
> Note that before GDB 10 goes out with this new exec-file-mismatch feature,
> we should sort out: https://sourceware.org/bugzilla/show_bug.cgi?id=25475
> as possibly fixing this bug might imply to change the options of
>    'set exec-file-mismatch'
> (see last comment in the bug).

Indeed we should.

I'll be sending the build ID validation patch to gdb-patches soon.

Thanks,
Pedro Alves