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]

Re: add-inferior / clone-inferior


Tom Tromey <tromey@redhat.com> wrote:

> Tom> The whole target stack needs to be switched out depending on which
> Tom> target is "active".  I guess one idea would be to make it depend on the
> Tom> current inferior.  But then I would worry whether the correct inferior
> Tom> is always selected when gdb is doing various operations.
> 
> Thinking about it some more, it may be simpler to associate the target
> stack with a program space, not an inferior.  This will have the same
> effect, but I think gdb is generally more careful about selecting a
> program space before doing an operation.  E.g., linespec already does
> this properly, breakpoints already do this properly, etc.
> 
> Tom> I wonder if there are other UI issues to consider.
> 
> One that comes to mind is what target is associated with an inferior
> created with add-inferior?  How could you change this inferior's target
> to connect it to some existing target?

Perhaps I misunderstand the question.  Initially, there is just a dummy
target.

Do a command like 'file' and you have an exec target.

Do a command like 'run' or 'attach' or 'target remote' or 'target
extended-remote' and your process stratum target is pushed on top of the
old file stratum target.

Do a command like 'kill' or 'detach' and your process stratum target is
popped and you are back at the exec stratum target -- the exec file --
at the top of your target stack.

> Also, some way to see the active targets would be needed.  "info target"
> already seems to be taken.
> 
> Tom

Two needs I see:

. you're trying to reuse a target that is currently in use and does not
support concurrent use by multiple inferiors.

When asking, as now, whether to kill the other use, just include the
inferior ID if it is different than the current inferior.

If the question caught the user by surprise, then he/she has been given
the information needed to investigate and make an informed decision.

. you want to know the full set of inferiors and their targets.

Seems somewhat esoteric.  Perhaps a maint command would be appropriate?
Say,

    maint inferiors targets <optional-inferior-list>

Giving as output the inferior id and the list of to_shortname values for
the targets within its target stack?


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