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

[Pedro Alves <palves@redhat.com>]

On 5/17/20 7:15 PM, Philippe Waroquiers via Gdb wrote:
> 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.

But this seems like a pretty benign problem?  But I'm not sure
I understood it.  What exactly goes wrong in this scenario?

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

IMO it isn't, because it is very common to have different
filenames (if you consider the whole path) for executable
loaded in gdb compared to the executable that the process is
running when you consider remote debugging.

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

No, I mean, let's consider the feature from scratch again.
I'm saying that IMHO filename comparison on its own is pretty
weak and annoyingly chatty.  I'd think e.g., a basename
match + segments match (compare addresses and sizes of 
of text, data, etc, segments) would already be much better.
But that's a path that's been considered in all other scenarios
where we have to match binaries, and ultimately, build ID
was invented to fix this kind of scenario without heuristics,
because heuristics can always fail.  

So given that we can do buildid matching, shouldn't we just forget
all other kinds of matching, and just stick with build id matching,
with no fallback?  I.e., add build id matching, remove the filename
matching, and raise the bar for any fallback matching -- as in if
you want some fallback, it has to be better than just filenames.

IIRC, the main motivation for the feature is when you attach to
a process running bar, while you have foo (completely unrelated to bar)
loaded in gdb.  GDB previously would assume that foo is the symbol file
for bar, so it gladly continued debugging bar with the foo binary.
Buildid detects this, and also detects the scenario of attaching to
a process that is running an older version of bar than the version
you have loaded in gdb (because you rebuilt the program before 
attaching, for example).

More contrived use cases can be imagined, but it seems to me like
if you want to catch them, then you're better off making sure your
binaries include build ids.  Which is true by default on modern
GNU/Linux OSs at least.

Thanks,
Pedro Alves