Re: RFC: ``detach remote''

[Andrew Cagney <ac131313@ges.redhat.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