Re: RFC: ``detach remote''

Andrew Cagney
2002-08-11T15:15:24Z

> 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