This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: ``detach remote''
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