Re: RFC: ``detach remote''

Daniel Jacobowitz
2002-08-07T19:49:46Z

On Wed, Aug 07, 2002 at 03:31:02PM -0400, Andrew Cagney wrote:
> >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:

I hate extended-remote (current implementation) :) My reasons for
hating it have to do with no separation between the local- and remote-
commands; in other words, the fact that "kill" doesn't kill the debug
agent, etc.

Do you know of stubs which use extended-remote? If it's only gdbserver
and similar process-level stubs (like maybe the libremote which people
keep saying will be released soon?), we have some flexibility with its
semantics.

> 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.

Actually, it consumes the reply; if it's an Enn packet the detach is
aborted. It just doesn't care if the remote acknowledges ("OK") or
ignores ("") the "D".

> 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.

Let's compare this idea with current reality, for reference: for both
Linux (non-i386; i386's is really fancy, and actually resumes on
detach, and has interesting process-level-debug hooks. I'm talking
about the simpler MIPS and PowerPC stubs) kgdb stubs and gdbserver,
which are the only stubs I'm really familiar with, detach causes the
connection to close but the process to remain stopped and the debug
agent to wait for a reconnection. This is independent of which
extended-remote mode we're in. I believe gdbserver's behaved this way
for a couple of years at least.

I don't like the idea of changing ``detach'' to mean resume. Detach,
it seems to me, should be the same as breaking the connection; and
resume should have to be explicit.

What do you think of this idea, regardless of remote vs extended-remote
(which I think should behave consistently in this regard):

detach:
Close the remote connection, stub waits
attach:
N/A, this is a local attach

new command "remote detach":
Debug agent detaches/resumes the program being debugged
The agent may or may not hang around (say, remote agents probably
don't, extended-remote agents probably do?)

For extended-remote (only?), new command "remote attach"
Debug agent attaches to a new program

--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer