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: Pedro Alves <palves at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Gary Benson <gbenson at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>, Philippe Waroquiers <philippe dot waroquiers at skynet dot be>
- Date: Wed, 13 May 2015 09:39:16 +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> <CADPb22SDB9qV1BgP2JmCxsu-E8QXDj1SLnCjBjGWn+g+1M7V7A at mail dot gmail dot com> <5551D7AD dot 8080500 at redhat dot com> <CADPb22RvXNSxaXibcKGTk1ZhUnGcAoaG2VuuthAp9zMNd1tXOQ at mail dot gmail dot com>
On 05/12/2015 05:03 PM, Doug Evans wrote:
> On Tue, May 12, 2015 at 3:36 AM, Pedro Alves <palves@redhat.com> wrote:
>> Another way to handle that would be to leave the file loaded
>> in inferior 1, and switch to a new inferior to investigate
>> the other process.
>
> Sorry, these things don't always occur to me before I hit Send.
>
> Switching to a new inferior is three steps.
> (gdb) add-inf
> (gdb) infer 2
> (gdb) attach PID
>
> IWBN to have something like the following
>
> (gdb) attach -n PID # "n" for "in new inferior"
I agree here. It's actually one thing that has been crossing
my mind recently. I've been experimenting a lot with gdb's CLI around
multi-thread and multi-inferior things, in context of
i/t sets (see [1]), and making it possible to have "attach" create
new inferiors would help. E.g., attaching to more than one process
would be nice, like "attach PID1 PID2" and "attach --all-children PID".
Maybe even make "attach PID" automatically decide to reuse the
same inferior, so that gdb; attach" reuses inferior 1, but if you've
already used inferior 1, "attach" creates another one.
We do something like that when "target extended-remote" finds multiple
processes already running on the server side.
For preparing a new inferior for "run", we
have "add-inferior -exec FILE", though maybe "file -n" would
be nicer.
[1] https://github.com/palves/gdb/commits/palves/itsets-wip-width
(note: very experimental, not ready for general feedback yet)
>
> I kinda would rather do it differently, because it's more than
> just "attach" where one would like to do something in a new inferior,
> and IWBN to solve them all with one new command (or extension
> of existing command). E.g., "new-inferior <command>", as in
> "new-inferior attach PID". Or some such.
Guess that could be the existing "add-inferior", as in
"add-inferior -exec PROG attach PID". Not really sure I
like that direction though. Seems less convenient and more
prone to have users forget/miss this usage than teaching
"attach" etc. directly to me.
In an i/t sets world, another option would be for commands
that create new inferiors to set the current focus to the just
created inferior(s). Then the following commands would simply
apply to the new inferiors.
>
> OTOH, "new-inferior pwd" doesn't make much sense,
> and "attach -n PID" is simple (we'd want to enumerate
> all such commands and make sure the same option letter is
> available for use in all of them).
Yeah.
Thanks,
Pedro Alves