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

[Philippe Waroquiers <philippe.waroquiers@skynet.be>]

On Sun, 2020-05-17 at 18:47 +0100, Pedro Alves wrote:
> On 5/17/20 6:24 AM, Philippe Waroquiers via Gdb wrote:
> > 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?

For sure, these scenarios are unusual, but it might be better
that the user knows what happens.  GDB silently deciding to use
another (physical) file than what the process really executes
is maybe not ideal.

E.g. I am wondering if the below will be visible and cause
an (understandable) warning/error/behaviour for the user:
If the user has debugged a first process with orig_exe,
then the user copied orig_exe to copy_orig_exe, and then GDB is
attached to a process that runs copy_orig_exe, the user does not expect
to have orig_exe protected/accessed anymore, and so might change it
or remove it or ..., while GDB still use orig_exe instead of copy_orig_exe.

So, I was wondering if such a case of equal build ID
but different (local?) file names are not worth a warning.

> 
> 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.
You mean that the filename comparison is useless (or even harmful)
if we found the build ID in the files ?
Effectively, if build ID are different but filenames are equal,
that is likely a false positive 'file are matching'
(only possible in remote debugging setup I suppose).

Philippe