This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: ``detach remote''
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.
Ignoring the implementation, there are a strong architectural grounds
for the extended-remote behavour.
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.
The only one that is of concern here is gdb/gdbserver. Given, to enable
extended-remote, the user has to type:
(gdb) remote extended-remote ....
I don't think many people use or know about it.
I also suspect that recent changes, such as daemon mode, may have had
unexepcted consequences. Unless you hang onto the process and/or add
mechanisms for attaching to a new process, daemon mode is pretty
useless. The latter would be correct, sounds like the former is what
happened :-(
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".
Ok.
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.
There are two categories of remote target.
- remote board/stub
- remote process/server
A board is always there, power cycle it, kick it, disconnect it,
reconnect to it, and it is still there. GDB is talking to a very raw
and very permenant target. The lifetime of the debug agent and the
corresponding board are the same (ignoring a few esoteric edge
conditions which really fall into remote process).
A process is more tempoary. Both the remote connection and the process
have lifetimes and their lifetimes are independant. Drop the connection
and the process still runs. Kill the process and the connection is
still live.
Extended-remote was added (I believe) to handle the second case -- a
remote process.
I think it is a failure to clearly differentiate between thses two cases
(and recongnise that the connection and remote process can have
different lifetimes) that has lead to the problems we have here.
> 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.
Er, detach should behave according to its specification vis:
(gdb) help detach
Detach a process or file previously attached.
If a process, it is no longer traced, and it continues its
execution. If you were debugging a file, the file is closed and gdb
no longer accesses it.
In the case of a remote process that should [I think clearly] apply to
the process and not the connection.
If the intent is to drop the connection, then something like ``target
none'' or ``target child''.
> 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?)
The user enters ``detach'' to disconnect from the process. Who cares if
it is local or remote.
> For extended-remote (only?), new command "remote attach"
> Debug agent attaches to a new program
The user enters ``attach PID''. Again, who cares if it is local or remote.
--
I think, the easiest way of doing things is to have:
target remote FOO
negotiate extended-remote. If the target supports it then enable it.
Otherwize fall back to primative remote that we see now.
enjoy,
Andrew