From: David Taylor <dtaylor@emc.com>
To: Tom Tromey <tromey@redhat.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: add-inferior / clone-inferior
Date: Wed, 22 May 2013 18:21:00 -0000 [thread overview]
Message-ID: <8702.1369246895@usendtaylorx2l> (raw)
In-Reply-To: <87ehczhy0c.fsf@fleche.redhat.com>
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?
next prev parent reply other threads:[~2013-05-22 18:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-20 14:43 David Taylor
2013-05-20 15:06 ` Luis Machado
2013-05-20 15:46 ` David Taylor
2013-05-20 15:52 ` Luis Machado
2013-05-21 1:01 ` Yao Qi
2013-05-21 13:15 ` David Taylor
2013-05-21 13:52 ` Tom Tromey
2013-05-21 14:35 ` David Taylor
2013-05-21 15:46 ` Tom Tromey
2013-05-22 14:47 ` Tom Tromey
2013-05-22 18:21 ` David Taylor [this message]
2013-05-22 18:50 ` Tom Tromey
2013-05-22 19:42 ` David Taylor
2013-05-22 20:21 ` Tom Tromey
2013-06-24 20:50 ` Tom Tromey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8702.1369246895@usendtaylorx2l \
--to=dtaylor@emc.com \
--cc=gdb@sourceware.org \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox