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

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:~$ 

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

> 
> 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 ?



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

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

Thanks

Philippe