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

[Pedro Alves <palves@redhat.com>]

On 5/17/20 10:43 PM, Philippe Waroquiers via Gdb wrote:
> On Sun, 2020-05-17 at 22:19 +0100, Pedro Alves wrote:
>> On 5/17/20 9:11 PM, Philippe Waroquiers wrote:
>>> On Sun, 2020-05-17 at 20:50 +0100, Pedro Alves wrote:
>>>>> 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?
>>> The user expects orig_exe to not be 'busy' anymore, and so
>>> expects to be able to freely modify it, without e.g. impacting
>>> the GDB session debugging the executable running copy_orig_exe.
>>> (I guess that orig_exe will not cause 'Text busy' error, as no
>>> process is still executing it from the kernel point of view).
>>
>> Do you really see these "Text busy" errors nowadays?  I don't
>> think I ever saw those on GNU/Linux.
> The below reproduces it for me:
> philippe@md:~$ cp /bin/sleep mysleep
> philippe@md:~$ ./mysleep 100&
> [1] 7721
> philippe@md:~$ echo coucou > mysleep 
> bash: mysleep: Text file busy
> philippe@md:~$ cat /etc/debian_version 
> 10.4
> philippe@md:~$ 

Ah, OK.  Yeah, OK if you try to write directly to the file
like that.  But no one does that.

> 
> Maybe typical linkers renaming or removing
> the exe file before re-creating it, and thereby avoiding (most of)
> text busy errors ?

Yeah, gcc/ld unlink the file before recreating it, so in essence
they don't write to the preexisting inode, they create a new one.

> 
>>
>> Still, I'm not seeing the same kind of problem that ending
>> up with the wrong binary loaded in GDB causes.  If you end
>> up with the wrong binary loaded in GDB, then GDB may
>> for example install breakpoints at the wrong addresses,
>> and that may even cause the inferior to crash, because the
>> breakpoint address may fall in the middle of instructions,
>> resulting in the inferior potentially executing invalid
>> instructions, or worse, executing valid instructions with
>> disastrous side effects.
> If the executable file is modified while GDB is busy using it,
> could that not cause some problems ?

How does filename detection help with this?  If GDB is busy
using it, you're already past the initial filename verification.
And if you modify the binary but don't change the filename,
then the filename verification doesn't help either.  There
are many ways to shoot yourself in the foot, I don't think
we need to protect against all of them.

> 
> 
> 
>>> So, my main original use case needs filename comparison :(.
>>
>> According to:
>>
>>  https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/developer_guide/compiling-build-id
>>
>> "Each executable or shared library built with Red Hat Enterprise Linux Server 6 or later is assigned a unique identification 160-bit SHA-1 string, generated as a checksum of selected parts of the binary. "
>>
>> Maybe older gold versions didn't emit the build id by default, while
>> GNU ld did.  I tried it with master gold, and it emits the build id 
>> by default.  does explicitly specifying --build-id on the link work?
>> Since you're already not using the default tools, you could tweak
>> your build system to explicitly request a build id?
> I will check tomorrow if I can persuade the build system
> to generate a build ID.
> If yes (and assuming all what we have to debug but we do not build
> ourselves has a build ID), then build ID will cover my use case.

Great, thanks.

> 
>>
>>> So, my main original use case needs filename comparison :(.
>>
>> I think that doesn't follow -- you could say that the build id
>> isn't sufficient for you, and that you need a fallback, but 
>> that doesn't mean that the fallback must be the straight
>> full path filename comparison as is it today.
> 
> The filename comparison was an easy way to cover the cases I saw,
> reasonably OS independent, while build ID is more precise
> but not working everywhere, so a fallback (whatever it is) for
> missing build ID situations would be useful.

OK.  But I argue that the filename matching is more harmful than
helpful (see e.g., the remote debugging scenarios I presented).
I would rather remove it before a release is out with it, and
consider a better fallback if one is found & needed.  If
we keep it, we also have to come up with ways to unbreak the
testsuite on the different configurations that are presently
broken for it.  That alone would be sufficient grounds for a
reversion until it is fixed, IMHO.

Thanks,
Pedro Alves