Re: RFC: ``detach remote''

[Andrew Cagney <ac131313@ges.redhat.com>]

> 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