This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: add-inferior / clone-inferior
- From: Tom Tromey <tromey at redhat dot com>
- To: David Taylor <dtaylor at emc dot com>
- Cc: gdb at sourceware dot org
- Date: Tue, 21 May 2013 09:30:02 -0600
- Subject: Re: add-inferior / clone-inferior
- References: <7249 dot 1369061005 at usendtaylorx2l>
>>>>> "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