Re: add-inferior / clone-inferior

[Tom Tromey <tromey@redhat.com>]

>>>>> "David" == David Taylor <dtaylor@emc.com> writes:

David> Looking at remote.c, it stores a global pointer to a structure
David> containing a file descriptor and other state in remote_desc.
David> This variable, and presumably others, are inferior specific.

It looks to me that someone made an attempt to isolate all the
per-remote data into struct remote_state, but then other developers went
ahead and added globals.

David> Looking at inferior.h I see:
David>   /* Private data used by the target vector implementation.  */
David>   struct private_inferior *private;
David> Based on the comment, the structure should probably be called
David> private_target rather than private_inferior.

I think rather this field should be removed and replaced with uses of
the inferior's registry (see registry.h) for those targets that need to
hang data on the inferior.

David> I'm thinking that remote.c should define a struct private_inferior
David> containing, at least, a pointer to 'struct serial *remote_desc' and then
David> *EITHER* changing inferiors needs to save / restore remote_desc (which
David> would mean target_ops entries for { saving / restoring } state when you
David> { switch away from / switch back to } an inferior *OR* all references to
David> remote_desc need to be modified to get to it via

I think using struct remote_state and not private_inferior, but yeah.

David> I'm also thinking that target_ops needs to have a couple of
David> additional fields:

David>     . a boolean -- does the target support multiple concurrent active
David>     instances?

David>     . a counter -- how many active instances do we currently have?

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

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

It seems like it would only work for target-async as well.
I suppose that is a given already.


The whole target stack needs to be switched out depending on which
target is "active".  I guess one idea would be to make it depend on the
current inferior.  But then I would worry whether the correct inferior
is always selected when gdb is doing various operations.

I think I'd also examine all the calls to push_target, unpush_target,
and target_is_pushed to make sure they are ok.  I think there are hidden
gotchas here.  E.g., "record" will eventually call push_target via
record_full_open -- which examines the current target stack and stores
stuff into a global.

I wonder if there are other UI issues to consider.

Also see the thread containing this message:

    http://sourceware.org/ml/gdb-patches/2010-06/msg00161.html

especially

    http://sourceware.org/ml/gdb-patches/2010-06/msg00200.html

I thought I remembered other discussions of this in the past, but the
above is all I could find.  Maybe we discussed it on irc.

It would be very nice to have a wiki page for this project, with the
plans and links.

Tom