This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: add-inferior / clone-inferior
- From: David Taylor <dtaylor at emc dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Tue, 21 May 2013 09:15:10 -0400
- Subject: Re: add-inferior / clone-inferior
- References: <7249 dot 1369061005 at usendtaylorx2l> <519AC76E dot 4040508 at codesourcery dot 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.