This is the mail archive of the gdb@sourceware.org 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]

add-inferior / clone-inferior


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.

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

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?

I'm also guessing that the above is just the tip of the iceberg or
someone would have already done this.

What else needs to happen for this to work?  I'm trying to get a feel
for how big a project this would be and whether it would be better for
us to pursue other options.

Thanks.

David

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.
--
David Taylor
dtaylor@emc.com


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