Re: RFC: ``detach remote''

[Daniel Jacobowitz <drow at mvista dot com>]

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

I'd agree more if there were a way to kill the debug agent gracefully
from GDB.

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

OK; so we have some room to adjust the way extended-remote behaves,
that we don't really have with remote.  Great.

> 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 :-(

To expand on what I said earlier: nothing "happened" in this regard
since daemon mode was never contributed.  I seem to recall that it had
a way to start new processes, but I'm not sure.

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

I'm not sure I 100% agree here.  The stub isn't always available; for
at least many non-ROM stubs, if they yield control to the process then
GDB can't reach the stub again.  Some of them offer ways to break back
into the stub from the running program; some don't.

I guess we could even indicate this distinction via extended-remote...
no, maybe not.  In any case the difference isn't terribly important.

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

Sure, this makes sense to me.

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

Hold on a second.  Gdbserver is in wide use; that may not have been
true a couple of years ago, but the reason I've invested so much time
in maintaining it is a continually growing customer demand for it.
People use this, and they are already used to its behavior.

This isn't to say we can't change the meaning of detach; but we need
to be aware that it's an interface change.

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

Anyone accustomed to the current behavior cares.

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

This is also an interface change worth thinking about.  Here's a
scenario; slightly outlandish, perhaps, but I've done it:

Start gdb
Connect to gdbserver (target remote)
detach
attach to local copy of same binary via ``attach PID''.

Admittedly there are better ways :)


==


My usual pessimisim aside, I think I like your idea.  We need to think
about the change a little more, because right now "detach" offers a way
to disconnect from the agent _without killing it_, for the normal
remote agent.  "target" would offer to kill it.  Got a suggestion for
what to call this new command?

I'd like detach to behave the "roughly" same way between remote and
extended-remote, especially if we're talking about autodetecing
extended-remote; that is, I'd like "detach" to say "not supported" when
using target remote, instead of maintaining its current behavior.  Make
sense?  And perhaps include a reference to the new way of detaching
from a target, whatever it may be.

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

I like this too.  But:
  - after some new commands have been added to increase the usability
of extended-remote
  - this is a separate patch if I've ever seen one :)

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