RFC: ``detach remote''

[Andrew Cagney]

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

That's just a user interface problem.  Easily fixed with another obscure 
command line option :-^

>> >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 think we should take liberties regardless.  It's like the CLI, 
eventually someone has to fix the design.

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

To take a positive twist, wicked!  It is possible to fix it without 
worrying about anything else before.

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

This is an optional feature (being able to BREAK the remote running 
program via the GDB console), just like remote breakpoints, or threads. 
   Such features are orthogonal to remote VS extended-remote behavour.

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

[Be careful to separate the interests of the fee paying customer from 
the interests of GDB and the wider GDB community.  Fee paying customers 
have an unfortunate habit of being very short sighted :-( :-)]

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

We need to be sure that the change provides advantages sufficient to 
provide good argument suporting the change.  We need to communicate that 
(hey the remote chapter in the doco :-).


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

People care when functionality is being removed and or replaced with 
something of inferior quality.  If the change comes with greatly 
enhanced usability and this is communicated to the user base then they 
are more accepting of the change.  No one ever said beep to the commands 
that were obsoleted in 5.0 (must remember to remove them :-).

I'm a user, and I'd prefer to be able to type:

	(gdb) target remote |ssh machine gdbagent
	(gdb) file foo
	(gdb) run
	Program exited
	<doh!>
	(gdb) break main
	(gdb) run
	...
	(gdb) detach
	(gdb) monitor ps
	(gdb) attach
	.....

instead of:

	(gdb) shell rsh machine gdbagent program ... &
	(gdb) target remote ...
	(gdb) continue
	Program exited
	<grrrrr>
	(gdb) shell rsh machine ps
	(gdb) shell rsh machine kill <gdbagent>
	(gdb) shell rsh machine gdbagent program ... &
	(gdb) target remote ....
	(gdb) break main
	(gdb) continue
	....
	(gdb) detach
	<Arg!!!>
	(gdb) shell rsh machine ps
	(gdb) shell rsh machine gdbagent -pid <pid> &
	(gdb) target remote ....
	....

:-)

btw


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

I think the command sequence would be:

	target remote
	attach <remote-pid>
	target child -- implicit remote/pid detach
	attach <local-pid>

(Red Herring -- ``target sim'' is equally confused.)

> ==
> 
> 
> 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?

[realism :-)]

I think you're saying that detach, for current gdbserver, drops the tcp 
connection but the server and the debugged program both hang around. 
That is a gdbserver decision and not, I think, GDB's problem.  If the 
GDB server decides to hang around, what does GDB care?

Mind you adding documented gdbserver options (and perhaphs a monitor 
command) to control this behavour wouldn't go astray.

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

or, print the warning message indicating that ``target none'' should be 
used to disconnect from the target.

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

Having had several false starts at trying to do this, I'm trying a new 
strategy --- obsolete the problem code :-)


enjoy,
Andrew