Re: [PATCH] Make only user-specified executable filenames sticky

Gary Benson
2015-05-13T07:55:08Z

Doug Evans wrote:
> On Tue, May 12, 2015 at 3:36 AM, Pedro Alves <palves@redhat.com> wrote:
> > On 05/11/2015 09:23 PM, Doug Evans wrote:
> > > On Wed, May 6, 2015 at 3:26 AM, Gary Benson <gbenson@redhat.com> wrote:
> > > > 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.
> > >
> > > I can imagine sometimes wanting either behaviour, depending on
> > > the situation.
> >
> > Yeah, AFAICS, both examples you gave work the same before
> > and after Gary's patch.
> >
> > > E.g., if I supply a file name do some stuff, and then change
> > > my mind or wish to investigate a difference process I may
> > > wish gdb to automagically pick up the file name of the new
> > > process.
> >
> > In that case, one can use "file; attach PID".
> >
> > That is, you can just unload the previous program, so that GDB
> > picks up the new one automatically on next attach.
>
> I realize one *could* do that.
> Thing is, someone's muscle memory may make them expect
> "attach PID" to Just Work.
> After all, "bash$ gdb" + "(gdb) attach PID" Just Works.
>
> Plus that's two steps.
> Why do I *have* to first type "file" with no arguments?
> (Joe User may be thinking)
> The difference in the two scenarios is explainable, but there's
> still an incongruity here.
>
> We go to lengths to reduce typing in the CLI session.
> IWBN if one could type, say,
> "attach -f PID" (f for "force gdb to use the binary of the attached
> process", or whatever).

I asked already, but nobody answered, so...

If you say "attach PID", and GDB can see that PID's executable is
/foo/bar, and the current exec-file is not /foo/bar/, under what
circumstances should GDB *not* automatically reload the new exec-
file? i.e. why could this "attach -f" behavior not be the default?

Cheers,
Gary

--