public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Gary Benson <gbenson@redhat.com>
To: Don Breazeal <donb@codesourcery.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
	       Joel Brobecker <brobecker@adacore.com>
Subject: Re: [PATCH] Make only user-specified executable filenames sticky
Date: Fri, 03 Jul 2015 11:14:00 -0000	[thread overview]
Message-ID: <20150703111418.GB15448@blade.nx> (raw)
In-Reply-To: <5571B828.1080208@codesourcery.com>

Don Breazeal wrote:
> On 6/5/2015 2:37 AM, Gary Benson wrote:
> > Don Breazeal wrote:
> > > On 5/6/2015 3:26 AM, Gary Benson wrote:
> > > > In GDB some executable files are supplied by the user
> > > > (e.g. using a "file" command) and some are determined by GDB
> > > > (e.g. while processing an "attach" command).  GDB will not
> > > > attempt to determine a filename if one has been set.  This
> > > > causes problems if you attach to one process and then attach
> > > > to another: GDB will not attempt to discover the main
> > > > executable on the second attach.  If the two processes have
> > > > different main executable files then the symbols will now be
> > > > wrong.
> > > >
> > > > This commit updates GDB to keep track of which executable
> > > > filenames were supplied by the user.  When GDB might attempt
> > > > to determine an executable filename and one is already set,
> > > > filenames determined by GDB may be overridden but
> > > > user-supplied filenames will not.
> > > 
> > > How does this interact with follow-exec-mode?  If
> > > follow-exec-mode is 'new' and the program execs, then 'run' will
> > > use the original executable file.  But if follow-exec-mode is
> > > 'same' and the program execs, then 'run' will use the executable
> > > file that was active after the exec call.
> > >
> > > In the follow-exec-mode == 'same' instance, is the assumption
> > > that the exec'd executable file takes on the same
> > > 'user-supplied' attribute as the initial executable, since it is
> > > using the original inferior?
> > >
> > > If so, is there a scenario where:
> > >  * the user supplies the exec file name
> > >  * the program execs, so the exec file name is now different
> > >  * then the user tries to do an attach (without an exec file name)
> > >    to a process running the original exec file, and gets the wrong
> > >    exec file name?
> > 
> > I'm not sure.  Where would I need to look to check this out?
> > (Where is the bit that updates the filename after exec?)
> 
> I think it goes like this: infrun.c:follow_exec calls
> exec.c:exec_file_attach, which updates the name of the executable.

Ah, there is exactly the scenario you describe Don, good call.
Joel, I can fix v3 of this patch to zero exec_file_is_user_supplied
before the exec_file_attach in follow_exec.

I'm not convinced this patch will not introduce new bugs, the whole
handling of how/where executable and/or symbol files get changed
seems... haphazard :)  That's mainly why I'd put this patch on the
back burner.

I'm on the fence as to whether this should be committed, so I'll
defer to you Joel.  If you say commit I'll re-test and push.

Cheers,
Gary

-- 
http://gbenson.net/

  reply	other threads:[~2015-07-03 11:14 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-02  9:48 qXfer:exec-file:read and non multiprocess target Philippe Waroquiers
2015-05-05 11:02 ` Gary Benson
2015-05-05 20:45   ` Philippe Waroquiers
2015-05-06 10:31     ` Gary Benson
2015-05-06 17:10       ` [PATCH] Locate executables on remote stubs without multiprocess extensions Gary Benson
2015-05-06 17:15         ` Eli Zaretskii
2015-05-06 17:16         ` Gary Benson
2015-05-11 14:37           ` Pedro Alves
2015-05-12 11:03             ` Gary Benson
2015-05-05 15:14 ` qXfer:exec-file:read and non multiprocess target Gary Benson
2015-05-06 10:26   ` [PATCH] Make only user-specified executable filenames sticky Gary Benson
2015-05-06 12:19     ` Pedro Alves
2015-05-06 14:21       ` Pedro Alves
2015-05-06 15:20       ` Gary Benson
2015-05-11 13:57         ` Pedro Alves
2015-05-06 14:46     ` Philippe Waroquiers
2015-05-06 15:41       ` Gary Benson
2015-05-11 13:58         ` Pedro Alves
2015-05-11 20:25       ` Doug Evans
2015-05-11 17:14     ` Don Breazeal
2015-06-05  9:37       ` Gary Benson
2015-06-05 14:54         ` Don Breazeal
2015-07-03 11:14           ` Gary Benson [this message]
2015-07-06 12:53             ` Joel Brobecker
2015-07-17 21:48             ` Joel Brobecker
2015-05-11 20:23     ` Doug Evans
2015-05-12 10:36       ` Pedro Alves
2015-05-12 11:13         ` Gary Benson
2015-05-12 11:16           ` Pedro Alves
2015-05-12 13:48             ` Gary Benson
2015-05-12 14:08               ` Pedro Alves
2015-05-12 15:49         ` Doug Evans
2015-05-13  7:55           ` Gary Benson
2015-05-13  9:12             ` Pedro Alves
2015-06-03 17:23               ` Joel Brobecker
2015-06-05 11:22                 ` [PATCH v2] Make only user-specified executable and symbol " Gary Benson
2015-06-07 11:40                   ` Philippe Waroquiers
2015-06-08  9:01                     ` [PATCH v3] " Gary Benson
2015-06-08 19:42                       ` Philippe Waroquiers
2015-07-03 11:01                         ` Gary Benson
2015-07-03 15:44                       ` Pedro Alves
2015-07-06 13:01                         ` Pedro Alves
2015-06-07 12:03                   ` [PATCH v2] " Philippe Waroquiers
2015-06-07 12:13                   ` Philippe Waroquiers
2015-05-13  8:06           ` [PATCH] Make only user-specified executable " Pedro Alves
2015-05-12 16:03         ` Doug Evans
2015-05-13  8:39           ` 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=20150703111418.GB15448@blade.nx \
    --to=gbenson@redhat.com \
    --cc=brobecker@adacore.com \
    --cc=donb@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    /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).