Re: add-inferior / clone-inferior

Tom Tromey <[email protected]> wrote:

> >>>>> "David" == David Taylor <[email protected]> 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