From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: Pedro Alves <palves@redhat.com>,
"Metzger, Markus T" <markus.t.metzger@intel.com>,
GDB <gdb@sourceware.org>
Subject: Re: exec-file-mismatch and native-gdbserver testing
Date: Sun, 17 May 2020 23:43:15 +0200 [thread overview]
Message-ID: <4f27f3f4aac0a9aae9da414b9668fa4a3fbf1a51.camel@skynet.be> (raw)
In-Reply-To: <7bf4097d-88ac-7016-bf0d-c1648ac8126b@redhat.com>
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
next prev parent reply other threads:[~2020-05-17 21:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-08 14:02 Metzger, Markus T
2020-04-08 20:54 ` Philippe Waroquiers
2020-04-09 6:30 ` Metzger, Markus T
2020-05-08 10:30 ` Metzger, Markus T
2020-05-08 21:25 ` Philippe Waroquiers
2020-05-16 20:10 ` Pedro Alves
2020-05-17 5:24 ` Philippe Waroquiers
2020-05-17 17:47 ` Pedro Alves
2020-05-17 18:15 ` Philippe Waroquiers
2020-05-17 19:50 ` Pedro Alves
2020-05-17 20:11 ` Philippe Waroquiers
2020-05-17 21:19 ` Pedro Alves
2020-05-17 21:43 ` Philippe Waroquiers [this message]
2020-05-17 21:58 ` Pedro Alves
2020-05-18 10:35 ` Philippe Waroquiers
2020-05-18 14:05 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4f27f3f4aac0a9aae9da414b9668fa4a3fbf1a51.camel@skynet.be \
--to=philippe.waroquiers@skynet.be \
--cc=gdb@sourceware.org \
--cc=markus.t.metzger@intel.com \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).