This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: add-inferior / clone-inferior
- From: Yao Qi <yao at codesourcery dot com>
- To: David Taylor <dtaylor at emc dot com>
- Cc: <gdb at sourceware dot org>
- Date: Tue, 21 May 2013 09:01:34 +0800
- Subject: Re: add-inferior / clone-inferior
- References: <7249 dot 1369061005 at usendtaylorx2l>
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 (éå)