Re: RFC: ``detach remote''

Andrew Cagney
2002-08-07T19:31:05Z

> 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