Re: RFC: ``detach remote''

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

> On Fri, Aug 09, 2002 at 01:48:25PM -0400, Andrew Cagney wrote:
>
> > >Hold on a second.  Gdbserver is in wide use; that may not have been
> > >true a couple of years ago, but the reason I've invested so much time
> > >in maintaining it is a continually growing customer demand for it.
> > >People use this, and they are already used to its behavior.
> > [Be careful to separate the interests of the fee paying customer from 
> > the interests of GDB and the wider GDB community.  Fee paying customers 
> > have an unfortunate habit of being very short sighted :-( :-)]
>
> I get more non-customer feedback on gdbserver than customer feedback,
> actually.  Poor choice of words.
I'm told HP once did a study to determine the debug requirements of a 
typical user.  Turns out a typical debug session looks something like:

	$ ./a.out
	segmentation fault, core dumped
	$ gdb ./a.out
	(gdb) run
	Program received sig seg
	10		a = *b;
	(gdb) print b
	$1 b = 0
	(gdb) quit

``Advanced users'' get to use up/down and backtrace.

Depressing, eh?

> > I'm a user, and I'd prefer to be able to type:
> >
> > 	(gdb) target remote |ssh machine gdbagent
> > 	(gdb) file foo
> > 	(gdb) run
> > 	Program exited
> > 	<doh!>
> > 	(gdb) break main
> > 	(gdb) run
> > 	...
> > 	(gdb) detach
> > 	(gdb) monitor ps
> > 	(gdb) attach
> > 	.....
> >
> > instead of:
>
> Some day :)  Those are nice ideas.
It's closer then you might thing.  All you need is:
- attach packet
- detach packet with a correct definition
- auto-negotiate of extended-remote

> > I think the command sequence would be:
> >
> > 	target remote
> > 	attach <remote-pid>
> > 	target child -- implicit remote/pid detach
> > 	attach <local-pid>
> >
> > (Red Herring -- ``target sim'' is equally confused.)
>
> The difficulty is what to call "disconnect from the agent".  I don't
> really like the ambiguity of the target stack here... I suppose adding
> a "target none" will suffice, but right now the behavior when unpushing
> a running target is to ask the user if they want to kill it.  That's
> not going to work if we use this as the method to detach and leave the
> agent running :)  Having "target none" detach and "target child" ask
> you if you want to kill doesn't really work either.
>
> What do you think of letting the target control what happens when
> another target is selected?  Remote targets could choose to detach. 
> That's a little better.
More background:

Looking at the code and recalling comments (some verbal), the original 
intent was that there could be several active targets.  This allows the 
user to switch between targets:

	target child
		a live process
	target core
		now look at the core file
	target child
		back to that live process

I don't know if it works.  I've never used it.

Turns out that this ideal was corrupted along the way because the 
implementation only allowed one target of each type.  As a consequence, 
``target remote'' and ``target sim'' both zap ``target child''.

> Or, hey, here's a better idea.  A "disconnect" command.  Then "target"
> can retain its current semantics (kill) and the user will have an
> explicit way to disconnect if they want.
Hmmm!

Noteing the above -- there can be multiple active targets -- therefor 
there does need to be a way of shutting down a specific target. 
Presumably ``target none'' would shutdown all of them.

Need to look at a table to see what operations are possible and then 
figure out which map onto commands.

enjoy,
Andrew