add-inferior / clone-inferior

add-inferior / clone-inferior

[David Taylor]

The commands add-inferior / clone-inferior and several related commands
were added as long ago as gdb 7.1.  But, unless I'm missing the obvious,
they aren't currently very useful.

GDB appears to support multiple "live" inferiors only when the arise as
the result of a fork or vfork.  Please tell me that I'm wrong and that
I'm missing the obvious.

    . I start up gdb with no arguments
    . file my-elf-file
    . clone-inferior
    . info inferiors

I now have two inferiors, numbers 1 and 2, same elf file; 1 is curent.

    . target remote <arguments>
    . inferior 2
    . target remote <different-arguments>

And I get:

    A program is being debugged already.  Kill it? (y or n)

I also tried attaching to two pre-existing processes, one each two
different inferiors.  That failed as well.

I've looked more at remote targets than attached / forked targets, as we
are more interested in remote targets.  Thursday last week I would have
loved to have had 10 inferiors, 5 elf files, 2 inferiors per elf file.

Looking at remote.c, it stores a global pointer to a structure
containing a file descriptor and other state in remote_desc.

This variable, and presumably others, are inferior specific.

Looking at inferior.h I see:

  /* Private data used by the target vector implementation.  */
  struct private_inferior *private;

Based on the comment, the structure should probably be called
private_target rather than private_inferior.

I'm thinking that remote.c should define a struct private_inferior
containing, at least, a pointer to 'struct serial *remote_desc' and then
*EITHER* changing inferiors needs to save / restore remote_desc (which
would mean target_ops entries for { saving / restoring } state when you
{ switch away from / switch back to } an inferior *OR* all references to
remote_desc need to be modified to get to it via

    current_inferior -> private -> remote_desc -> ...

I'm also thinking that target_ops needs to have a couple of additional fields:

    . a boolean -- does the target support multiple concurrent active
    instances?

    . a counter -- how many active instances do we currently have?

I'm also guessing that the above is just the tip of the iceberg or
someone would have already done this.

What else needs to happen for this to work?  I'm trying to get a feel
for how big a project this would be and whether it would be better for
us to pursue other options.

Thanks.

David

p.s.  It would also be nice if inferiors could be named, otherwise
you'll end up creating a crib sheet telling you which is which.  It's
trivial, but it makes me think that no one really uses add-inferior /
clone-inferior.
--
David Taylor
dtaylor@emc.com

Re: add-inferior / clone-inferior

[Luis Machado]

On 05/20/2013 04:43 PM, David Taylor wrote:
> The commands add-inferior / clone-inferior and several related commands
> were added as long ago as gdb 7.1.  But, unless I'm missing the obvious,
> they aren't currently very useful.
>
> GDB appears to support multiple "live" inferiors only when the arise as
> the result of a fork or vfork.  Please tell me that I'm wrong and that
> I'm missing the obvious.
>
>      . I start up gdb with no arguments
>      . file my-elf-file
>      . clone-inferior
>      . info inferiors
>
> I now have two inferiors, numbers 1 and 2, same elf file; 1 is curent.
>
>      . target remote <arguments>
>      . inferior 2
>      . target remote <different-arguments>
>
> And I get:
>
>      A program is being debugged already.  Kill it? (y or n)

This is expected since you can actually have two inferiors, but you are 
only allowed to connect to a single remote target at one time.

What would've worked is first connecting to a remote target in 
*extended* remote mode. Then you would be able to attach to more than a 
process at a time, or start more than a process at a time.

By using "target remote", you're really trying to debug an already 
active process running on a remote system.

I'd suggest reading about the extended remote mode. That looks like what 
you want, though multiprocess support is still a WIP.

Re: add-inferior / clone-inferior

[David Taylor]

Luis Machado <lgustavo@codesourcery.com> wrote:

> This is expected since you can actually have two inferiors, but you are 
> only allowed to connect to a single remote target at one time.
> 
> What would've worked is first connecting to a remote target in 
> *extended* remote mode. Then you would be able to attach to more than a 
> process at a time, or start more than a process at a time.
> 
> By using "target remote", you're really trying to debug an already 
> active process running on a remote system.
> 
> I'd suggest reading about the extended remote mode. That looks like what 
> you want, though multiprocess support is still a WIP.

Actually, no.  The issue is not extended-remote vs remote.  We have boxes
with multiple boards each running a kernel.  The box I tried running gdb
against on Thursday has 10 boards of interest.  Each running its own
instance of the kernel -- 2 instances each of 5 different versions of
the kernel.

For that machine if I want to talk to all 10 boards, then I need 10
different tcp connections -- each talking to a different gdb stub.

Re: add-inferior / clone-inferior

[Luis Machado]

On 05/20/2013 05:46 PM, David Taylor wrote:
> Luis Machado <lgustavo@codesourcery.com> wrote:
>
>> This is expected since you can actually have two inferiors, but you are
>> only allowed to connect to a single remote target at one time.
>>
>> What would've worked is first connecting to a remote target in
>> *extended* remote mode. Then you would be able to attach to more than a
>> process at a time, or start more than a process at a time.
>>
>> By using "target remote", you're really trying to debug an already
>> active process running on a remote system.
>>
>> I'd suggest reading about the extended remote mode. That looks like what
>> you want, though multiprocess support is still a WIP.
>
> Actually, no.  The issue is not extended-remote vs remote.  We have boxes
> with multiple boards each running a kernel.  The box I tried running gdb
> against on Thursday has 10 boards of interest.  Each running its own
> instance of the kernel -- 2 instances each of 5 different versions of
> the kernel.

Ok. It just seemed like the example you used was incorrectly assuming 
"target remote" would be able to do what "target extended-remote" does.

>
> For that machine if I want to talk to all 10 boards, then I need 10
> different tcp connections -- each talking to a different gdb stub.

In the current scenario you would probably need a specialized debugging 
stub that would be able to multiplex between all of those boards. I've 
worked with a similar system before.

As for making GDB accept all those different connections at the same 
time, i don't think it is currently prepared for that.

Luis

Re: add-inferior / clone-inferior

[Yao Qi]

On 05/20/2013 10:43 PM, David Taylor wrote:
> The commands add-inferior / clone-inferior and several related commands
> were added as long ago as gdb 7.1.  But, unless I'm missing the obvious,
> they aren't currently very useful.
>
> GDB appears to support multiple "live" inferiors only when the arise as
> the result of a fork or vfork.  Please tell me that I'm wrong and that
> I'm missing the obvious.
>
>      . I start up gdb with no arguments
>      . file my-elf-file
>      . clone-inferior
>      . info inferiors
>
> I now have two inferiors, numbers 1 and 2, same elf file; 1 is curent.
>
>      . target remote <arguments>
>      . inferior 2
>      . target remote <different-arguments>
>
> And I get:
>
>      A program is being debugged already.  Kill it? (y or n)
>
> I also tried attaching to two pre-existing processes, one each two
> different inferiors.  That failed as well.

David,
GDB supports multiple inferiors in a single remote target (in 
extended-remote mode).  GDB can't talk with multiple remote targets in 
parallel so far.  What you need/want is GDB talks with multiple remote 
targets (GDBserver on different boards).

>
> I've looked more at remote targets than attached / forked targets, as we
> are more interested in remote targets.  Thursday last week I would have
> loved to have had 10 inferiors, 5 elf files, 2 inferiors per elf file.
>
> Looking at remote.c, it stores a global pointer to a structure
> containing a file descriptor and other state in remote_desc.
>
> This variable, and presumably others, are inferior specific.
>
> Looking at inferior.h I see:
>
>    /* Private data used by the target vector implementation.  */
>    struct private_inferior *private;
>
> Based on the comment, the structure should probably be called
> private_target rather than private_inferior.
>
> I'm thinking that remote.c should define a struct private_inferior
> containing, at least, a pointer to 'struct serial *remote_desc' and then
> *EITHER* changing inferiors needs to save / restore remote_desc (which
> would mean target_ops entries for { saving / restoring } state when you
> { switch away from / switch back to } an inferior *OR* all references to
> remote_desc need to be modified to get to it via
>
>      current_inferior -> private -> remote_desc -> ...
>

Probably, each inferior should be ref-count'ed the remote_desc, because 
multiple inferiors may share the same remote_desc, and the connection 
leak can be avoided.  I am not the people design and write this part of 
code, but I don't see something wrong in your thoughts.

> I'm also thinking that target_ops needs to have a couple of additional fields:
>
>      . a boolean -- does the target support multiple concurrent active
>      instances?
>
>      . a counter -- how many active instances do we currently have?
>

What do you mean by "instance" here?  a process on a target board 
physically?

>
> p.s.  It would also be nice if inferiors could be named, otherwise
> you'll end up creating a crib sheet telling you which is which.  It's
> trivial, but it makes me think that no one really uses add-inferior /
> clone-inferior.

In terms of naming, we are proposing ITSET (inferior/thread set) or 
PTSET (process/thread set) to GDB 
<http://sourceware.org/ml/gdb-patches/2013-04/msg00031.html>.  With 
ITSET, you can name a set of inferiors:

(gdb) defset foo i1-2  // define named itset 'foo' for inferior 1 and 2
(gdb) defset bar i3-4  // define named itset 'foo' for inferior 3 and 4

and you can apply command to named set via proposed command 'scope':

// detach from inferiors in set 'foo'.
(gdb) scope foo detach
// check the stack backtrace of inferiors in set 'bar'.
(gdb) scope bar bt
// generate corefile for each process in set 'foo' and 'bar'.
(gdb) scope bar,foo gcore

Hope ITSET is helpful on your naming issue.

-- 
Yao (齐尧)

Re: add-inferior / clone-inferior

[David Taylor]

Yao Qi <yao@codesourcery.com> wrote:

>On 05/20/2013 10:43 PM, David Taylor wrote:

>David,
>GDB supports multiple inferiors in a single remote target (in 
>extended-remote mode).  GDB can't talk with multiple remote targets in 
>parallel so far.  What you need/want is GDB talks with multiple remote 
>targets (GDBserver on different boards).

I want to have separate sockets at GDB's end.  I do not want to have a
"meta stub" (not really a good name, but nothing better quickly comes to
mind) on the local box that managers tcp connections and peeks into the
packets to determine when to set up or break down a new tcp connection
and where to send the packets.

That is, I do not want to do:

    target extended-remote | <some-program> <some-arguments>

And then have <some-program> look at the contents of each an every
packet to decide whether it is something for it to act on or something
to forward on.

THat approach is UGLY.

Each remote end is a separate kernel.


>> I'm also thinking that target_ops needs to have a couple of additional fields:
>>
>>      . a boolean -- does the target support multiple concurrent active
>>      instances?
>>
>>      . a counter -- how many active instances do we currently have?
>>
>
>What do you mean by "instance" here?  a process on a target board 
>physically?

It's a reference counter -- it's how many inferiors (as shown by, say,
info inferiors) have this target as their target.

If the first field is false -- the target does not support concurrent
active instances -- then the counter effectively becomes a boolean -- is
there currently an inferior with this target as its target?

>> p.s.  It would also be nice if inferiors could be named, otherwise
>> you'll end up creating a crib sheet telling you which is which.  It's
>> trivial, but it makes me think that no one really uses add-inferior /
>> clone-inferior.
>
>In terms of naming, we are proposing ITSET (inferior/thread set) or 
>PTSET (process/thread set) to GDB 
><http://sourceware.org/ml/gdb-patches/2013-04/msg00031.html>.  With 
>ITSET, you can name a set of inferiors:
>
>(gdb) defset foo i1-2  // define named itset 'foo' for inferior 1 and 2
>(gdb) defset bar i3-4  // define named itset 'foo' for inferior 3 and 4
>
>and you can apply command to named set via proposed command 'scope':
>
>// detach from inferiors in set 'foo'.
>(gdb) scope foo detach
>// check the stack backtrace of inferiors in set 'bar'.
>(gdb) scope bar bt
>// generate corefile for each process in set 'foo' and 'bar'.
>(gdb) scope bar,foo gcore
>
>Hope ITSET is helpful on your naming issue.

I think that having named sets of the inferiors would be useful as well.
With an inferior potentially being a member in zero or more sets.

And you could think of names as being sets with unique elements.  But, I
was thinking of something simpler -- a unique user settable field that
shows up when you do 'info inferiors' or the like -- that could,
hopefully, be used anywhere that the existing ID is used.

Re: add-inferior / clone-inferior

[Tom Tromey]

>>>>> "David" == David Taylor <dtaylor@emc.com> writes:

David> I want to have separate sockets at GDB's end.  I do not want to have a
David> "meta stub" (not really a good name, but nothing better quickly comes to
David> mind) on the local box that managers tcp connections and peeks into the
David> packets to determine when to set up or break down a new tcp connection
David> and where to send the packets.

I've been calling that a "federating gdbserver".
It federates multiple instances into a single server.

David> THat approach is UGLY.

It has one advantage -- you can link them together hierarchically, so
gdb can talk to more remote servers than it has available file
descriptors.


Anyway, I certainly want gdb to be multi-target-capable.  I think others
do too.  It just requires someone to do the work.

Tom

Re: add-inferior / clone-inferior

[David Taylor]

Tom Tromey <tromey@redhat.com> wrote:

> >>>>> "David" == David Taylor <dtaylor@emc.com> writes:
> 
> David> I want to have separate sockets at GDB's end.  I do not want to have a
> David> "meta stub" (not really a good name, but nothing better quickly comes to
> David> mind) on the local box that managers tcp connections and peeks into the
> David> packets to determine when to set up or break down a new tcp connection
> David> and where to send the packets.
> 
> I've been calling that a "federating gdbserver".
> It federates multiple instances into a single server.
> 
> David> THat approach is UGLY.
> 
> It has one advantage -- you can link them together hierarchically, so
> gdb can talk to more remote servers than it has available file
> descriptors.

Agreed.  But, if you hit the limit then either you're on a system with a
low limit on number of per process file descriptors or you are dealing
with an awful lot of connections.

> Anyway, I certainly want gdb to be multi-target-capable.  I think others
> do too.  It just requires someone to do the work.
> 
> Tom

Agreed.  And that has been the case for more than a decade.  When I saw
the add-inferior / clone-inferior commands and noticed that they were
part of 7.1, I thought that by now someone had done the work and I just
somehow missed noticing.

When I posted a brief list of things that needed to be done to get it to
work for remote targets (i.e., target { remote | extended-remote }), I
felt confident that I left some steps out and was hoping that others
would list some of the missing items.  Also, it's been a decade since I
last worked on GDB full time...  So, I'd like a second opinion on how
big a task this is.

Part of the purpose of the proposed two new fields for the 'struct
target' is to allow targets to be converted one at a time.  If you try
to use a target twice that hasn't been conveted, you would get an error.

David

Re: add-inferior / clone-inferior

[Tom Tromey]

>>>>> "David" == David Taylor <dtaylor@emc.com> writes:

David> Looking at remote.c, it stores a global pointer to a structure
David> containing a file descriptor and other state in remote_desc.
David> This variable, and presumably others, are inferior specific.

It looks to me that someone made an attempt to isolate all the
per-remote data into struct remote_state, but then other developers went
ahead and added globals.

David> Looking at inferior.h I see:
David>   /* Private data used by the target vector implementation.  */
David>   struct private_inferior *private;
David> Based on the comment, the structure should probably be called
David> private_target rather than private_inferior.

I think rather this field should be removed and replaced with uses of
the inferior's registry (see registry.h) for those targets that need to
hang data on the inferior.

David> I'm thinking that remote.c should define a struct private_inferior
David> containing, at least, a pointer to 'struct serial *remote_desc' and then
David> *EITHER* changing inferiors needs to save / restore remote_desc (which
David> would mean target_ops entries for { saving / restoring } state when you
David> { switch away from / switch back to } an inferior *OR* all references to
David> remote_desc need to be modified to get to it via

I think using struct remote_state and not private_inferior, but yeah.

David> I'm also thinking that target_ops needs to have a couple of
David> additional fields:

David>     . a boolean -- does the target support multiple concurrent active
David>     instances?

David>     . a counter -- how many active instances do we currently have?

David> I'm also guessing that the above is just the tip of the iceberg or
David> someone would have already done this.

David> What else needs to happen for this to work?  I'm trying to get a feel
David> for how big a project this would be and whether it would be better for
David> us to pursue other options.

It seems like it would only work for target-async as well.
I suppose that is a given already.


The whole target stack needs to be switched out depending on which
target is "active".  I guess one idea would be to make it depend on the
current inferior.  But then I would worry whether the correct inferior
is always selected when gdb is doing various operations.

I think I'd also examine all the calls to push_target, unpush_target,
and target_is_pushed to make sure they are ok.  I think there are hidden
gotchas here.  E.g., "record" will eventually call push_target via
record_full_open -- which examines the current target stack and stores
stuff into a global.

I wonder if there are other UI issues to consider.

Also see the thread containing this message:

    http://sourceware.org/ml/gdb-patches/2010-06/msg00161.html

especially

    http://sourceware.org/ml/gdb-patches/2010-06/msg00200.html

I thought I remembered other discussions of this in the past, but the
above is all I could find.  Maybe we discussed it on irc.

It would be very nice to have a wiki page for this project, with the
plans and links.

Tom

Re: add-inferior / clone-inferior

[Tom Tromey]

Tom> The whole target stack needs to be switched out depending on which
Tom> target is "active".  I guess one idea would be to make it depend on the
Tom> current inferior.  But then I would worry whether the correct inferior
Tom> is always selected when gdb is doing various operations.

Thinking about it some more, it may be simpler to associate the target
stack with a program space, not an inferior.  This will have the same
effect, but I think gdb is generally more careful about selecting a
program space before doing an operation.  E.g., linespec already does
this properly, breakpoints already do this properly, etc.

Tom> I wonder if there are other UI issues to consider.

One that comes to mind is what target is associated with an inferior
created with add-inferior?  How could you change this inferior's target
to connect it to some existing target?

Also, some way to see the active targets would be needed.  "info target"
already seems to be taken.

Tom

Re: add-inferior / clone-inferior

[David Taylor]

Tom Tromey <tromey@redhat.com> wrote:

> Tom> The whole target stack needs to be switched out depending on which
> Tom> target is "active".  I guess one idea would be to make it depend on the
> Tom> current inferior.  But then I would worry whether the correct inferior
> Tom> is always selected when gdb is doing various operations.
> 
> Thinking about it some more, it may be simpler to associate the target
> stack with a program space, not an inferior.  This will have the same
> effect, but I think gdb is generally more careful about selecting a
> program space before doing an operation.  E.g., linespec already does
> this properly, breakpoints already do this properly, etc.
> 
> Tom> I wonder if there are other UI issues to consider.
> 
> One that comes to mind is what target is associated with an inferior
> created with add-inferior?  How could you change this inferior's target
> to connect it to some existing target?

Perhaps I misunderstand the question.  Initially, there is just a dummy
target.

Do a command like 'file' and you have an exec target.

Do a command like 'run' or 'attach' or 'target remote' or 'target
extended-remote' and your process stratum target is pushed on top of the
old file stratum target.

Do a command like 'kill' or 'detach' and your process stratum target is
popped and you are back at the exec stratum target -- the exec file --
at the top of your target stack.

> Also, some way to see the active targets would be needed.  "info target"
> already seems to be taken.
> 
> Tom

Two needs I see:

. you're trying to reuse a target that is currently in use and does not
support concurrent use by multiple inferiors.

When asking, as now, whether to kill the other use, just include the
inferior ID if it is different than the current inferior.

If the question caught the user by surprise, then he/she has been given
the information needed to investigate and make an informed decision.

. you want to know the full set of inferiors and their targets.

Seems somewhat esoteric.  Perhaps a maint command would be appropriate?
Say,

    maint inferiors targets <optional-inferior-list>

Giving as output the inferior id and the list of to_shortname values for
the targets within its target stack?

Re: add-inferior / clone-inferior

[Tom Tromey]

Tom> One that comes to mind is what target is associated with an inferior
Tom> created with add-inferior?  How could you change this inferior's target
Tom> to connect it to some existing target?

David> Perhaps I misunderstand the question.  Initially, there is just a dummy
David> target.

David> Do a command like 'file' and you have an exec target.

David> Do a command like 'run' or 'attach' or 'target remote' or 'target
David> extended-remote' and your process stratum target is pushed on top of the
David> old file stratum target.

David> Do a command like 'kill' or 'detach' and your process stratum target is
David> popped and you are back at the exec stratum target -- the exec file --
David> at the top of your target stack.

I was thinking of a scenario like: I have an existing connection to an
extended-remote target, then I want to add an inferior and then run it
on that target.

I guess something like this would work if "target extended-remote"
always did connection sharing:

    add-inferior -exec whatever
    target extended-remote server:port
    run

The issue I have is differentiating this from the scenario of: add
inferior, connect for the first time, then try to run.  Won't this do
something different if the remote is already running?

I feel like I'm confused somehow.

David> . you want to know the full set of inferiors and their targets.

David> Seems somewhat esoteric.  Perhaps a maint command would be appropriate?

I suppose we could just print it in "info inferiors".

Tom

Re: add-inferior / clone-inferior

[David Taylor]

Tom Tromey <tromey@redhat.com> wrote:

> Tom> One that comes to mind is what target is associated with an inferior
> Tom> created with add-inferior?  How could you change this inferior's target
> Tom> to connect it to some existing target?
> 
> David> Perhaps I misunderstand the question.  Initially, there is just a dummy
> David> target.
> 
> David> Do a command like 'file' and you have an exec target.
> 
> David> Do a command like 'run' or 'attach' or 'target remote' or 'target
> David> extended-remote' and your process stratum target is pushed on top of the
> David> old file stratum target.
> 
> David> Do a command like 'kill' or 'detach' and your process stratum target is
> David> popped and you are back at the exec stratum target -- the exec file --
> David> at the top of your target stack.
> 
> I was thinking of a scenario like: I have an existing connection to an
> extended-remote target, then I want to add an inferior and then run it
> on that target.
> 
> I guess something like this would work if "target extended-remote"
> always did connection sharing:
> 
>     add-inferior -exec whatever
>     target extended-remote server:port
>     run
> 
> The issue I have is differentiating this from the scenario of: add
> inferior, connect for the first time, then try to run.  Won't this do
> something different if the remote is already running?
> 
> I feel like I'm confused somehow.

I wasn't thinking about that scenario.  My current interest is talking
to the kernel of a machine that might be in a local lab or might be at a
customer site half way around the world.  The existing kernel stub does
not multiplex between boards.  Each board has its own kernel.  If you
want to multiplex between kernels, you have to do it at a higher level.
I'd rather not have an intermediate server that inspects the packets,
acts on some and passes the others on.

But, if you give it a different server:port than previously, presumably
you want it to open a new connection.  I think it needs to be clear to
the user whether it is reusing an existing connection or creating a new
one.  Perhaps a different syntax than server:port when reusing a
connection?

Maybe,

    target extended-remote @<existing-inferior-id>

with an empty <existing-inferior-id> [i.e., just '@' for an argument]
meaning use the current inferior.

Unless you think that a user would always do one or always do the other,
rarely switching, in which case perhaps a settable flag would be
appropriate?

> David> . you want to know the full set of inferiors and their targets.
> 
> David> Seems somewhat esoteric.  Perhaps a maint command would be appropriate?
> 
> I suppose we could just print it in "info inferiors".

If we just printed the top stratum element putting it into info
inferiors is probably reasonable.  If it was more verbose, I don't think
the average user would care to see it.

I'd also like a name field somewhere for the inferior.  I can envision
debugging a client server problem by having both under one GDB rather
than two GDBs.  Ideally, names that the 'inferior' command recognizes
in addition to a numeric inferior id.  Then I could do

    inferior client
    ... some commands ...
    inferior server
    ... some commands ...

> Tom

David

Re: add-inferior / clone-inferior

[Tom Tromey]

David> I wasn't thinking about that scenario.  My current interest is talking
David> to the kernel of a machine that might be in a local lab or might be at a
David> customer site half way around the world.

Yeah.

I'm just brainstorming different scenarios to try to understand what
problems multi-target might have.  Running a new program via an
extended-remote gdbserver seems like a reasonable thing to want to do;
but I wasn't sure of the mechanics.

David> But, if you give it a different server:port than previously, presumably
David> you want it to open a new connection.  I think it needs to be clear to
David> the user whether it is reusing an existing connection or creating a new
David> one.  Perhaps a different syntax than server:port when reusing a
David> connection?

Yeah, that may be the way to go.

Or maybe "always reuse" is best?  Since it seems unlikely to want to
open multiple concurrent connections to the exact same server/port pair.
(I guess it could work with some hypothetical gdbserver.  But I don't
think it exists.)

David> If we just printed the top stratum element putting it into info
David> inferiors is probably reasonable.  If it was more verbose, I don't think
David> the average user would care to see it.

I was just thinking something like:

(gdb) info inferior
  Num  Description       Executable        Target
* 1    process 2994      /usr/bin/gdb      native
  2    process 1222      /bin/sh           server:9999

David> I'd also like a name field somewhere for the inferior.  I can envision
David> debugging a client server problem by having both under one GDB rather
David> than two GDBs.  Ideally, names that the 'inferior' command recognizes
David> in addition to a numeric inferior id.  Then I could do
David>     inferior client
David>     ... some commands ...
David>     inferior server
David>     ... some commands ...

IT sets were the answer to this in the past, but I see in your other
mail that you also wanted it to show up in "info inferiors".  That seems
reasonable to me; though maybe it could be some kind of itset flag.

I think Pedro and Yao have the best status on itsets.

Tom

Re: add-inferior / clone-inferior

[Tom Tromey]

Tom> The whole target stack needs to be switched out depending on which
Tom> target is "active".  I guess one idea would be to make it depend on the
Tom> current inferior.  But then I would worry whether the correct inferior
Tom> is always selected when gdb is doing various operations.

Tom> I think I'd also examine all the calls to push_target, unpush_target,
Tom> and target_is_pushed to make sure they are ok.  I think there are hidden
Tom> gotchas here.  E.g., "record" will eventually call push_target via
Tom> record_full_open -- which examines the current target stack and stores
Tom> stuff into a global.

I played with this a bit last week and again today.

I have it working well enough that I can run one inferior while visiting
a core file in another.

I'll push my branch eventually; sooner if somebody wants to see it.

Tom> I wonder if there are other UI issues to consider.

Pedro pointed out a few on irc.
They're in the notes on the branch.

Tom> It would be very nice to have a wiki page for this project, with the
Tom> plans and links.

I'll set one up.

Tom