This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]