Re: RFC: ``detach remote''

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

> So, the GDB manual has this to say about remote debugging:
>
>      To resume the remote program and stop debugging it, use the `detach'
>   command.
>
> This is not how gdbserver works, and it isn't how any stubs I've worked with
> behave, either.  They'll sit and wait for a reconnection.  Rather than
> change the status quo, I would like to update the documentation and provide
> a way to get the previously documented behavior.  This uses the "K" packet
> described in my email to gdb@ last week.  The new command is `detach remote'
> which I'm not thrilled with but I'm a little short on ideas.  It's hard to
> find something to call this.
>
> GDB and gdbserver patches attached.  Comments?
I don't think this is right - either for GDB or for the remote debug 
agent.  Local or remote, the user should be able to use:

	[attach PID]
	detach

The remote protocol has two modes -- ``remote'' and ``extended-remote''. 
 In the latter case, GDB doesn't drop the connection -- it assumes that 
the remote end will stay around.  (Lets ignore my desire to merge the 
pair and instead have remote probe the other end for extended-remote 
support :-)  Hence:

In ``remote'' mode.  A detach command should: drop the tcp connection; 
set the process free.

In ``extended-remote'' mode.  A detach coommand should: set the process 
free.  (Lets also ignore that there is no attach mechanism :-).

That leaves the question of how to implement it using protocol 
mechanisms.  The ``D'' is messed up, GDB sends the D and then totally 
ignores the reply.

As for remote debug agents, the ones I've used (pretty sure this applied 
to gdbserver when I last used it) quit as soon as the connection went 
down.  An explict daemon mode was required to make them hang around.

enjoy,
Andrew