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: Tom Tromey <tromey at redhat dot com>
- Cc: Yao Qi <yao at codesourcery dot com>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Tue, 21 May 2013 10:34:54 -0400
- Subject: Re: add-inferior / clone-inferior
- References: <7249 dot 1369061005 at usendtaylorx2l> <519AC76E dot 4040508 at codesourcery dot com> <20412 dot 1369142110 at usendtaylorx2l> <87li78l9t7 dot fsf at fleche dot redhat dot com>
Tom Tromey <tromey@redhat.com> wrote:
> >>>>> "David" == David Taylor <dtaylor@emc.com> 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