Re: add-inferior / clone-inferior

[David Taylor <dtaylor@emc.com>]

Tom Tromey <tromey@redhat.com> wrote:

> Tom> One that comes to mind is what target is associated with an inferior
> Tom> created with add-inferior?  How could you change this inferior's target
> Tom> to connect it to some existing target?
> 
> David> Perhaps I misunderstand the question.  Initially, there is just a dummy
> David> target.
> 
> David> Do a command like 'file' and you have an exec target.
> 
> David> Do a command like 'run' or 'attach' or 'target remote' or 'target
> David> extended-remote' and your process stratum target is pushed on top of the
> David> old file stratum target.
> 
> David> Do a command like 'kill' or 'detach' and your process stratum target is
> David> popped and you are back at the exec stratum target -- the exec file --
> David> at the top of your target stack.
> 
> I was thinking of a scenario like: I have an existing connection to an
> extended-remote target, then I want to add an inferior and then run it
> on that target.
> 
> I guess something like this would work if "target extended-remote"
> always did connection sharing:
> 
>     add-inferior -exec whatever
>     target extended-remote server:port
>     run
> 
> The issue I have is differentiating this from the scenario of: add
> inferior, connect for the first time, then try to run.  Won't this do
> something different if the remote is already running?
> 
> I feel like I'm confused somehow.

I wasn't thinking about that scenario.  My current interest is talking
to the kernel of a machine that might be in a local lab or might be at a
customer site half way around the world.  The existing kernel stub does
not multiplex between boards.  Each board has its own kernel.  If you
want to multiplex between kernels, you have to do it at a higher level.
I'd rather not have an intermediate server that inspects the packets,
acts on some and passes the others on.

But, if you give it a different server:port than previously, presumably
you want it to open a new connection.  I think it needs to be clear to
the user whether it is reusing an existing connection or creating a new
one.  Perhaps a different syntax than server:port when reusing a
connection?

Maybe,

    target extended-remote @<existing-inferior-id>

with an empty <existing-inferior-id> [i.e., just '@' for an argument]
meaning use the current inferior.

Unless you think that a user would always do one or always do the other,
rarely switching, in which case perhaps a settable flag would be
appropriate?

> David> . you want to know the full set of inferiors and their targets.
> 
> David> Seems somewhat esoteric.  Perhaps a maint command would be appropriate?
> 
> I suppose we could just print it in "info inferiors".

If we just printed the top stratum element putting it into info
inferiors is probably reasonable.  If it was more verbose, I don't think
the average user would care to see it.

I'd also like a name field somewhere for the inferior.  I can envision
debugging a client server problem by having both under one GDB rather
than two GDBs.  Ideally, names that the 'inferior' command recognizes
in addition to a numeric inferior id.  Then I could do

    inferior client
    ... some commands ...
    inferior server
    ... some commands ...

> Tom

David