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


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