add-inferior / clone-inferior

Yao Qi
Tue May 21 01:01:00 GMT 2013

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.

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 

> 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 
<>.  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 (齐尧)

More information about the Gdb mailing list