This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: add-inferior / clone-inferior

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.

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

     . 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 /

In terms of naming, we are proposing ITSET (inferior/thread set) or PTSET (process/thread set) to GDB <>. 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 (éå)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]