Re: add-inferior / clone-inferior

[David Taylor <dtaylor@emc.com>]

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.