Re: add-inferior / clone-inferior

[Yao Qi <yao@codesourcery.com>]

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