This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Make only user-specified executable filenames sticky
- From: Gary Benson <gbenson at redhat dot com>
- To: Don Breazeal <donb at codesourcery dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>, Joel Brobecker <brobecker at adacore dot com>
- Date: Fri, 3 Jul 2015 12:14:18 +0100
- Subject: Re: [PATCH] Make only user-specified executable filenames sticky
- Authentication-results: sourceware.org; auth=none
- References: <20150505151448 dot GA1417 at blade dot nx> <1430907977-30605-1-git-send-email-gbenson at redhat dot com> <5550E357 dot 9040209 at codesourcery dot com> <20150605093724 dot GA26604 at blade dot nx> <5571B828 dot 1080208 at codesourcery dot 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/