RFC: ``detach remote''

RFC: ``detach remote''

[Daniel Jacobowitz]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

So, the GDB manual has this to say about remote debugging:

     To resume the remote program and stop debugging it, use the `detach'
  command.

This is not how gdbserver works, and it isn't how any stubs I've worked with
behave, either.  They'll sit and wait for a reconnection.  Rather than
change the status quo, I would like to update the documentation and provide
a way to get the previously documented behavior.  This uses the "K" packet
described in my email to gdb@ last week.  The new command is `detach remote'
which I'm not thrilled with but I'm a little short on ideas.  It's hard to
find something to call this.

GDB and gdbserver patches attached.  Comments?


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

[-- Attachment #2: detach-2.client.patch --]
[-- Type: text/plain, Size: 4364 bytes --]

2002-08-06  Daniel Jacobowitz  <drow@mvista.com>

	* remote.c (remote_detach): Support `detach remote'.
	(remote_async_detach): Likewise.

2002-08-06  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.texinfo: Document `detach remote'.
	(Remote Protocol): Document `K' packet.

Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.89
diff -u -p -r1.89 remote.c
--- remote.c	23 Jul 2002 18:55:06 -0000	1.89
+++ remote.c	6 Aug 2002 20:49:59 -0000
@@ -2496,17 +2496,28 @@ remote_detach (char *args, int from_tty)
   struct remote_state *rs = get_remote_state ();
   char *buf = alloca (rs->remote_packet_size);
 
-  if (args)
-    error ("Argument given to \"detach\" when remotely debugging.");
-
-  /* Tell the remote target to detach.  */
-  strcpy (buf, "D");
-  remote_send (buf, (rs->remote_packet_size));
+  if (args && strcmp (args, "remote") == 0)
+    {
+      /* Tell the target to detach and resume the inferior.  */
+      putpkt ("K");
+      getpkt (buf, rs->remote_packet_size, 0);
+      if (strcmp (buf, "ERR") == 0)
+	error ("Remote target refused to detach.");
+      else if (strcmp (buf, "OK") != 0)
+	error ("Remote target does not support detaching.");
+    }
+  else if (args)
+    error ("Unknown argument given to \"detach\".");
+  else
+    {
+      /* Tell the remote target to detach.  */
+      strcpy (buf, "D");
+      remote_send (buf, (rs->remote_packet_size));
+    }
 
   target_mourn_inferior ();
   if (from_tty)
     puts_filtered ("Ending remote debugging.\n");
-
 }
 
 /* Same as remote_detach, but with async support. */
@@ -2516,12 +2527,24 @@ remote_async_detach (char *args, int fro
   struct remote_state *rs = get_remote_state ();
   char *buf = alloca (rs->remote_packet_size);
 
-  if (args)
-    error ("Argument given to \"detach\" when remotely debugging.");
-
-  /* Tell the remote target to detach.  */
-  strcpy (buf, "D");
-  remote_send (buf, (rs->remote_packet_size));
+  if (args && strcmp (args, "remote") == 0)
+    {
+      /* Tell the target to detach and resume the inferior.  */
+      putpkt ("K");
+      getpkt (buf, rs->remote_packet_size, 0);
+      if (strcmp (buf, "ERR") == 0)
+	error ("Remote target refused to detach.");
+      else if (strcmp (buf, "OK") != 0)
+	error ("Remote target does not support detaching.");
+    }
+  else if (args)
+    error ("Unknown argument given to \"detach\".");
+  else
+    {
+      /* Tell the remote target to detach.  */
+      strcpy (buf, "D");
+      remote_send (buf, (rs->remote_packet_size));
+    }
 
   /* Unregister the file descriptor from the event loop. */
   if (target_is_async_p ())
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.107
diff -u -p -r1.107 gdb.texinfo
--- doc/gdb.texinfo	3 Aug 2002 23:37:07 -0000	1.107
+++ doc/gdb.texinfo	6 Aug 2002 20:50:03 -0000
@@ -10784,8 +10784,11 @@ session.
 Now you can use all the usual commands to examine and change data and to
 step and continue the remote program.
 
-To resume the remote program and stop debugging it, use the @code{detach}
-command.
+To end remote debugging, use the @code{detach} command.  Most remote stubs
+will wait for @value{GDBN} to reconnect; for some stubs, you can use
+@code{detach remote} to cause the stub to resume the remote program.
+Depending on the remote stub, this may cause the stub to exit or become
+unavailable.
 
 @cindex interrupting remote programs
 @cindex remote programs, interrupting
@@ -14502,6 +14505,20 @@ See @samp{i} and @samp{S} for likely syn
 @tab
 FIXME: @emph{There is no description of how to operate when a specific
 thread context has been selected (i.e.@: does 'k' kill only that thread?)}.
+
+@item Detach request
+@tab @code{K}
+@tab
+Detach @value{GDBN} from the remote system.  Sent to the remote target before
+@value{GDBN} disconnects.  This packet indicates that the inferior should
+be resumed instead of kept stopped, waiting for @value{GDBN} to reconnect.
+The stub may exit after replying to this packet, or may wait for @value{GDBN}.
+@item
+@tab reply @code{ERR}
+@tab The stub should return failure if it can not detach or refuses to detach.
+@item
+@tab reply @code{OK}
+@tab Success
 
 @item reserved
 @tab @code{l}

[-- Attachment #3: detach-2.server.patch --]
[-- Type: text/plain, Size: 3062 bytes --]

2002-08-06  Daniel Jacobowitz  <drow@mvista.com>

	* gdbserver/linux-low.c (linux_detach_one_process)
	(linux_detach): New.
	(linux_target_ops): Add linux_detach.
	* gdbserver/server.c (main): Recognize `K' packet.
	* gdbserver/target.h (struct target_ops): Add ``detach''
	member.
	(detach_inferior): New.

Index: gdbserver/linux-low.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/linux-low.c,v
retrieving revision 1.18
diff -u -p -r1.18 linux-low.c
--- gdbserver/linux-low.c	18 Jul 2002 15:18:02 -0000	1.18
+++ gdbserver/linux-low.c	6 Aug 2002 20:50:03 -0000
@@ -232,13 +232,28 @@ linux_kill_one_process (struct inferior_
     } while (WIFSTOPPED (wstat));
 }
 
-/* Return nonzero if the given thread is still alive.  */
 static void
 linux_kill (void)
 {
   for_each_inferior (&all_threads, linux_kill_one_process);
 }
 
+static void
+linux_detach_one_process (struct inferior_list_entry *entry)
+{
+  struct thread_info *thread = (struct thread_info *) entry;
+  struct process_info *process = get_thread_process (thread);
+
+  ptrace (PTRACE_DETACH, pid_of (process), 0, 0);
+}
+
+static void
+linux_detach (void)
+{
+  for_each_inferior (&all_threads, linux_detach_one_process);
+}
+
+/* Return nonzero if the given thread is still alive.  */
 static int
 linux_thread_alive (int tid)
 {
@@ -1261,6 +1276,7 @@ static struct target_ops linux_target_op
   linux_create_inferior,
   linux_attach,
   linux_kill,
+  linux_detach,
   linux_thread_alive,
   linux_resume,
   linux_wait,
Index: gdbserver/server.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/server.c,v
retrieving revision 1.13
diff -u -p -r1.13 server.c
--- gdbserver/server.c	11 Jun 2002 17:32:40 -0000	1.13
+++ gdbserver/server.c	6 Aug 2002 20:50:03 -0000
@@ -310,6 +310,19 @@ main (int argc, char *argv[])
 		  exit (0);
 		  break;
 		}
+	    case 'K':
+	      if (attached)
+		{
+		  fprintf (stderr, "Detaching from inferior\n");
+		  detach_inferior ();
+		  write_ok (own_buf);
+		  putpkt (own_buf);
+		  remote_close ();
+		  exit (0);
+		}
+	      else
+		write_enn (own_buf);
+	      break;
 	    case 'T':
 	      if (mythread_alive (strtol (&own_buf[1], NULL, 16)))
 		write_ok (own_buf);
Index: gdbserver/target.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/target.h,v
retrieving revision 1.4
diff -u -p -r1.4 target.h
--- gdbserver/target.h	11 Jun 2002 17:32:40 -0000	1.4
+++ gdbserver/target.h	6 Aug 2002 20:50:03 -0000
@@ -48,6 +48,10 @@ struct target_ops
 
   void (*kill) (void);
 
+  /* Detach from all inferiors.  */
+
+  void (*detach) (void);
+
   /* Return 1 iff the thread with process ID PID is alive.  */
 
   int (*thread_alive) (int pid);
@@ -123,6 +127,9 @@ void set_target_ops (struct target_ops *
 
 #define kill_inferior() \
   (*the_target->kill) ()
+
+#define detach_inferior() \
+  (*the_target->detach) ()
 
 #define mythread_alive(pid) \
   (*the_target->thread_alive) (pid)

Re: RFC: ``detach remote''

[Eli Zaretskii]

On Tue, 6 Aug 2002, Daniel Jacobowitz wrote:

>      To resume the remote program and stop debugging it, use the `detach'
>   command.
> 
> This is not how gdbserver works, and it isn't how any stubs I've worked with
> behave, either.  They'll sit and wait for a reconnection.  Rather than
> change the status quo, I would like to update the documentation and provide
> a way to get the previously documented behavior.  This uses the "K" packet
> described in my email to gdb@ last week.  The new command is `detach remote'
> which I'm not thrilled with but I'm a little short on ideas.  It's hard to
> find something to call this.
> 
> GDB and gdbserver patches attached.  Comments?

The documentation patch is approved.  Thanks.

Re: RFC: ``detach remote''

[Andrew Cagney]

> So, the GDB manual has this to say about remote debugging:
> 
>      To resume the remote program and stop debugging it, use the `detach'
>   command.
> 
> This is not how gdbserver works, and it isn't how any stubs I've worked with
> behave, either.  They'll sit and wait for a reconnection.  Rather than
> change the status quo, I would like to update the documentation and provide
> a way to get the previously documented behavior.  This uses the "K" packet
> described in my email to gdb@ last week.  The new command is `detach remote'
> which I'm not thrilled with but I'm a little short on ideas.  It's hard to
> find something to call this.
> 
> GDB and gdbserver patches attached.  Comments?

I don't think this is right - either for GDB or for the remote debug 
agent.  Local or remote, the user should be able to use:

	[attach PID]
	detach

The remote protocol has two modes -- ``remote'' and ``extended-remote''. 
  In the latter case, GDB doesn't drop the connection -- it assumes that 
the remote end will stay around.  (Lets ignore my desire to merge the 
pair and instead have remote probe the other end for extended-remote 
support :-)  Hence:

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.

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.

enjoy,
Andrew

Re: RFC: ``detach remote''

[Daniel Jacobowitz]

On Wed, Aug 07, 2002 at 03:31:02PM -0400, Andrew Cagney wrote:
> >So, the GDB manual has this to say about remote debugging:
> >
> >     To resume the remote program and stop debugging it, use the `detach'
> >  command.
> >
> >This is not how gdbserver works, and it isn't how any stubs I've worked 
> >with
> >behave, either.  They'll sit and wait for a reconnection.  Rather than
> >change the status quo, I would like to update the documentation and provide
> >a way to get the previously documented behavior.  This uses the "K" packet
> >described in my email to gdb@ last week.  The new command is `detach 
> >remote'
> >which I'm not thrilled with but I'm a little short on ideas.  It's hard to
> >find something to call this.
> >
> >GDB and gdbserver patches attached.  Comments?
> 
> I don't think this is right - either for GDB or for the remote debug 
> agent.  Local or remote, the user should be able to use:
> 
> 	[attach PID]
> 	detach
> 
> The remote protocol has two modes -- ``remote'' and ``extended-remote''. 
>  In the latter case, GDB doesn't drop the connection -- it assumes that 
> the remote end will stay around.  (Lets ignore my desire to merge the 
> pair and instead have remote probe the other end for extended-remote 
> support :-)  Hence:

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.

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.

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

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


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.


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

For extended-remote (only?), new command "remote attach"
  Debug agent attaches to a new program


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

Re: RFC: ``detach remote''

[Andrew Cagney]

> 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

Re: RFC: ``detach remote''

[Daniel Jacobowitz]

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

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

Re: RFC: ``detach remote''

[Daniel Jacobowitz]

On Fri, Aug 09, 2002 at 01:48:25PM -0400, Andrew Cagney wrote:
> >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 :-( :-)]

I get more non-customer feedback on gdbserver than customer feedback,
actually.  Poor choice of words.

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

Some day :)  Those are nice ideas.

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

The difficulty is what to call "disconnect from the agent".  I don't
really like the ambiguity of the target stack here... I suppose adding
a "target none" will suffice, but right now the behavior when unpushing
a running target is to ask the user if they want to kill it.  That's
not going to work if we use this as the method to detach and leave the
agent running :)  Having "target none" detach and "target child" ask
you if you want to kill doesn't really work either.

What do you think of letting the target control what happens when
another target is selected?  Remote targets could choose to detach. 
That's a little better.

Or, hey, here's a better idea.  A "disconnect" command.  Then "target"
can retain its current semantics (kill) and the user will have an
explicit way to disconnect if they want.

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

Need to decide what it should be first.

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

Sure...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: ``detach remote''

[Andrew Cagney]

> On Fri, Aug 09, 2002 at 01:48:25PM -0400, Andrew Cagney wrote:
> 
>> >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 :-( :-)]
> 
> 
> I get more non-customer feedback on gdbserver than customer feedback,
> actually.  Poor choice of words.

I'm told HP once did a study to determine the debug requirements of a 
typical user.  Turns out a typical debug session looks something like:

	$ ./a.out
	segmentation fault, core dumped
	$ gdb ./a.out
	(gdb) run
	Program received sig seg
	10		a = *b;
	(gdb) print b
	$1 b = 0
	(gdb) quit

``Advanced users'' get to use up/down and backtrace.

Depressing, eh?

>> 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:
> 
> 
> Some day :)  Those are nice ideas.

It's closer then you might thing.  All you need is:
- attach packet
- detach packet with a correct definition
- auto-negotiate of extended-remote

>> 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.)
> 
> 
> The difficulty is what to call "disconnect from the agent".  I don't
> really like the ambiguity of the target stack here... I suppose adding
> a "target none" will suffice, but right now the behavior when unpushing
> a running target is to ask the user if they want to kill it.  That's
> not going to work if we use this as the method to detach and leave the
> agent running :)  Having "target none" detach and "target child" ask
> you if you want to kill doesn't really work either.
> 
> What do you think of letting the target control what happens when
> another target is selected?  Remote targets could choose to detach. 
> That's a little better.

More background:

Looking at the code and recalling comments (some verbal), the original 
intent was that there could be several active targets.  This allows the 
user to switch between targets:

	target child
		a live process
	target core
		now look at the core file
	target child
		back to that live process

I don't know if it works.  I've never used it.

Turns out that this ideal was corrupted along the way because the 
implementation only allowed one target of each type.  As a consequence, 
``target remote'' and ``target sim'' both zap ``target child''.

> Or, hey, here's a better idea.  A "disconnect" command.  Then "target"
> can retain its current semantics (kill) and the user will have an
> explicit way to disconnect if they want.

Hmmm!

Noteing the above -- there can be multiple active targets -- therefor 
there does need to be a way of shutting down a specific target. 
Presumably ``target none'' would shutdown all of them.

Need to look at a table to see what operations are possible and then 
figure out which map onto commands.

enjoy,
Andrew

Re: RFC: ``detach remote''

[Daniel Jacobowitz]

On Sun, Aug 11, 2002 at 11:15:07AM -0400, Andrew Cagney wrote:
> >On Fri, Aug 09, 2002 at 01:48:25PM -0400, Andrew Cagney wrote:
> >
> >>>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 :-( :-)]
> >
> >
> >I get more non-customer feedback on gdbserver than customer feedback,
> >actually.  Poor choice of words.
> 
> I'm told HP once did a study to determine the debug requirements of a 
> typical user.  Turns out a typical debug session looks something like:
> 
> 	$ ./a.out
> 	segmentation fault, core dumped
> 	$ gdb ./a.out
> 	(gdb) run
> 	Program received sig seg
> 	10		a = *b;
> 	(gdb) print b
> 	$1 b = 0
> 	(gdb) quit
> 
> ``Advanced users'' get to use up/down and backtrace.
> 
> Depressing, eh?

Yeah.  It's certainly not universal, though...

> >>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:
> >
> >
> >Some day :)  Those are nice ideas.
> 
> It's closer then you might thing.  All you need is:
> - attach packet
> - detach packet with a correct definition
> - auto-negotiate of extended-remote

And pipe support for target remote, and an agent which can communicate
over said pipe.  Neither terribly hard...

> >>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.)
> >
> >
> >The difficulty is what to call "disconnect from the agent".  I don't
> >really like the ambiguity of the target stack here... I suppose adding
> >a "target none" will suffice, but right now the behavior when unpushing
> >a running target is to ask the user if they want to kill it.  That's
> >not going to work if we use this as the method to detach and leave the
> >agent running :)  Having "target none" detach and "target child" ask
> >you if you want to kill doesn't really work either.
> >
> >What do you think of letting the target control what happens when
> >another target is selected?  Remote targets could choose to detach. 
> >That's a little better.
> 
> More background:
> 
> Looking at the code and recalling comments (some verbal), the original 
> intent was that there could be several active targets.  This allows the 
> user to switch between targets:
> 
> 	target child
> 		a live process
> 	target core
> 		now look at the core file
> 	target child
> 		back to that live process
> 
> I don't know if it works.  I've never used it.
> 
> Turns out that this ideal was corrupted along the way because the 
> implementation only allowed one target of each type.  As a consequence, 
> ``target remote'' and ``target sim'' both zap ``target child''.

It doesn't work, anyway:
(gdb) target core core
A program is being debugged already.  Kill it? (y or n) 

I think that if you really want this to work, you need to have target
instances; so that saying "target core" creates a new instance of a
core target and you can control instances individually.  This is a long
way away and it isn't a goal I'm terribly interested in implementing.

> >Or, hey, here's a better idea.  A "disconnect" command.  Then "target"
> >can retain its current semantics (kill) and the user will have an
> >explicit way to disconnect if they want.
> 
> Hmmm!
> 
> Noteing the above -- there can be multiple active targets -- therefor 
> there does need to be a way of shutting down a specific target. 
> Presumably ``target none'' would shutdown all of them.

No, noting above, there might someday be multiple active targets. 
We're not there yet.

> Need to look at a table to see what operations are possible and then 
> figure out which map onto commands.

Tables and lists, I can do that!  Let's see what we've got.  I'll pick
a sampling of targets and operations.

Start with native debugging.  The basic things one wants are:
 - "run": create a new process.
 - "attach": Attach to a running process.
 - "detach": Detach from the current process.  Let it run.
 - "kill": End the current process.

I think we agree that the current meanings of these commands are right,
yes?

Then consider remote debugging of a simple ROM monitor.  All four of
the above commands are meaningless.  Currently, the only one of them
with meaning is "detach", which sends a D packet and disconnects.  The
ROM monitor can choose to remain stopped (most do, from what I've seen)
or resume when it sees the D packet.  It would be nice to have the
choice; I think that detach vs. disconnect is a reasonable way to
represent this.  Protocol side to be determined.  Perhaps disconnect
would send no packet at all, just close the connection?  I think that
would work.  But I digress.  Also, some ROM monitors might support
"restart", which currently gets lumped in with "run", but I believe
should be a special monitor command instead.  That might vary.

Then consider a simulator, linked in.
 - "run" means to restart the simulator
 - "kill" means to end the simulation
 - attach and detach have no apparent meaning
 - disconnect appears to have no useful meaning

Then consider a simulator, speaking a remote protocol, whichever remote
protocol it may be (I hypothesize that it should be extended-remote and
should reject some commands as inappropriate):
 - run/kill/attach/detach as above
 - disconnect now has meaning as with the ROM monitor

Now let's consider our friend the hypothetical all-singing all-dancing
remote process agent.  I think we've concluded that we want
"run"/"kill"/"attach"/"detach" to behave as with native debugging.  We
also need a couple of other commands:
 - Disconnect from the agent, leaving it in its current state, waiting
   for a new client
 - Terminate the agent

Terminating the agent can be a monitor command.  I like the idea of a
"disconnect" command.


One other thorny issue becomes what to do when the user quits or closes
the remote target etc.  Right now GDB offers the "kill" prompt as I
showed above.  For extended-remote that doesn't make a lot of sense to
me... I think that either "disconnect" or a "kill"/"terminate" sequence
makes more sense.  Thoughts?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: ``detach remote''

[Andrew Cagney]

> It's closer then you might thing.  All you need is:
>> - attach packet
>> - detach packet with a correct definition
>> - auto-negotiate of extended-remote
> 
> 
> And pipe support for target remote, and an agent which can communicate
> over said pipe.  Neither terribly hard...

Ever tried:
	target remote |cat
:-)

Re: RFC: ``detach remote''

[Daniel Jacobowitz]

On Sun, Aug 11, 2002 at 12:42:18PM -0400, Andrew Cagney wrote:
> >It's closer then you might thing.  All you need is:
> >>- attach packet
> >>- detach packet with a correct definition
> >>- auto-negotiate of extended-remote
> >
> >
> >And pipe support for target remote, and an agent which can communicate
> >over said pipe.  Neither terribly hard...
> 
> Ever tried:
> 	target remote |cat
> :-)

Well, I'll be something-or-othered!  If only that were, say, in the
documentation anywhere...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: ``detach remote''

[Andrew Cagney]

> On Sun, Aug 11, 2002 at 11:15:07AM -0400, Andrew Cagney wrote:

> It doesn't work, anyway:
> (gdb) target core core
> A program is being debugged already.  Kill it? (y or n) 
> 
> I think that if you really want this to work, you need to have target
> instances; so that saying "target core" creates a new instance of a
> core target and you can control instances individually.  This is a long
> way away and it isn't a goal I'm terribly interested in implementing.

I'm sure it did work.  Hmm, I can create this:

(gdb)
Program received signal SIGINT, Interrupt.
0x41cd3a98 in ?? () from /usr/lib/libc.so.12
(top-gdb) print target_stack->target_ops->to_longname
$17 = 0x1b0a040 "Unix child process"
(top-gdb) print target_stack->next->target_ops->to_longname
$18 = 0x1b09840 "Local core dump file"
(top-gdb) print target_stack->next->next->target_ops->to_longname
$19 = 0x1af87e4 "Local exec file"
(top-gdb) print target_stack->next->next->next->target_ops->to_longname
$20 = 0x1af5530 "None"

Oh, well.

>> >Or, hey, here's a better idea.  A "disconnect" command.  Then "target"
>> >can retain its current semantics (kill) and the user will have an
>> >explicit way to disconnect if they want.
> 
>> 
>> Hmmm!
>> 
>> Noteing the above -- there can be multiple active targets -- therefor 
>> there does need to be a way of shutting down a specific target. 
>> Presumably ``target none'' would shutdown all of them.
> 
> 
> No, noting above, there might someday be multiple active targets. 
> We're not there yet.

We've an active core file and unix child.  Just can't get back to the 
core file.

Btw, check this message:

(top-gdb) target core
No core file specified.  (Use `detach' to stop debugging a core file.)


>> Need to look at a table to see what operations are possible and then 
>> figure out which map onto commands.
> 
> 
> Tables and lists, I can do that!  Let's see what we've got.  I'll pick
> a sampling of targets and operations.
> 
> Start with native debugging.  The basic things one wants are:
>  - "run": create a new process.
>  - "attach": Attach to a running process.
>  - "detach": Detach from the current process.  Let it run.
>  - "kill": End the current process.
> 
> I think we agree that the current meanings of these commands are right,
> yes?

For target the comment reads:

(top-gdb) help target
Connect to a target machine or process.
The first argument is the type or protocol of the target machine.
Remaining arguments are interpreted by the target protocol.  For more
information on the arguments for a particular protocol, type
`help target ' followed by the protocol name.

Note the use of the words ``protocol'' and ``machine''.  I.e. ``target 
...'' establishes a physical connection.

> Then consider remote debugging of a simple ROM monitor.  All four of
> the above commands are meaningless.  Currently, the only one of them
> with meaning is "detach", which sends a D packet and disconnects.  The
> ROM monitor can choose to remain stopped (most do, from what I've seen)
> or resume when it sees the D packet.

When GDB attaches to a remote target, there is similar confusion.  Its 
assumed that there is already a remote program and it has stopped. 
``remote cisco'' assumes that the target is still running, you need to 
interrupt it.

>  It would be nice to have the
> choice; I think that detach vs. disconnect is a reasonable way to
> represent this.  Protocol side to be determined.  Perhaps disconnect
> would send no packet at all, just close the connection?  I think that
> would work.  But I digress.  Also, some ROM monitors might support
> "restart", which currently gets lumped in with "run", but I believe
> should be a special monitor command instead.  That might vary.

So the possible transactions:

	close connection
		options: kill, detach, continue, none
	open connection
		initial state: stopped, dead, running
	detach
	kill
	attach
	start
	continue

I think an existing simple remote target either:
	close / continue
		- target allowed to run but not detached
	close / none
		- target still attached but not resumed


``restart'' is something of a peverted form of run/continue.  The 
program eventually stops again.  Another way of handling it is:

	(gdb) monitor restart
	-> qRcmd ``restart''
	<- T<stop packet>

> Then consider a simulator, linked in.
>  - "run" means to restart the simulator
>  - "kill" means to end the simulation
>  - attach and detach have no apparent meaning
>  - disconnect appears to have no useful meaning
> 
> Then consider a simulator, speaking a remote protocol, whichever remote
> protocol it may be (I hypothesize that it should be extended-remote and
> should reject some commands as inappropriate):
>  - run/kill/attach/detach as above
>  - disconnect now has meaning as with the ROM monitor

See include/gdb/remote-sim.h.

The PPC simulator can live in either the remote, or the extended-remote 
world.  It is somewhat unique in this regard.

Other simulators live in the pure remote world -- it is trying to mimic 
an embedded board.

Stan Shebs and I had a very long debate (many many years ago) about what 
the sim model in GDB should be.  The status-quo, modeling a bare board 
(Stan), has so far prevailed.

> Now let's consider our friend the hypothetical all-singing all-dancing
> remote process agent.  I think we've concluded that we want
> "run"/"kill"/"attach"/"detach" to behave as with native debugging.  We
> also need a couple of other commands:
>  - Disconnect from the agent, leaving it in its current state, waiting
>    for a new client
>  - Terminate the agent
> 
> Terminating the agent can be a monitor command.  I like the idea of a
> "disconnect" command.

Either a monitor command or an agent option.  Exit on disconnect.

> One other thorny issue becomes what to do when the user quits or closes
> the remote target etc.  Right now GDB offers the "kill" prompt as I
> showed above.  For extended-remote that doesn't make a lot of sense to
> me... I think that either "disconnect" or a "kill"/"terminate" sequence
> makes more sense.  Thoughts?

The sequence is:

(gdb) attach 20856
Attaching to program: /home/scratch/GDB/native/gdb/gdb, process 20856
0x41b44a04 in ?? ()
(gdb) target core gdb.core
A program is being debugged already.  Kill it? (y or n)

In certain situtations, yes that message doesn't make sense.  The 
default [y] should still be to do something pretty fatal though. 
Perhaphs suggest ``detaching'' first.

Andrew

Re: RFC: ``detach remote''

[Daniel Jacobowitz]

More later, but:

On Sun, Aug 11, 2002 at 02:02:09PM -0400, Andrew Cagney wrote:
> (top-gdb) target core
> No core file specified.  (Use `detach' to stop debugging a core file.)

... which uses detach for its current meaning of `disconnect' rather
than the `process detach' we're now saying would be better.

> > It would be nice to have the
> >choice; I think that detach vs. disconnect is a reasonable way to
> >represent this.  Protocol side to be determined.  Perhaps disconnect
> >would send no packet at all, just close the connection?  I think that
> >would work.  But I digress.  Also, some ROM monitors might support
> >"restart", which currently gets lumped in with "run", but I believe
> >should be a special monitor command instead.  That might vary.
> 
> So the possible transactions:
> 
> 	close connection
> 		options: kill, detach, continue, none
> 	open connection
> 		initial state: stopped, dead, running
> 	detach
> 	kill
> 	attach
> 	start
> 	continue

And it's not clear what close/continue would mean in some cases, e.g.
gdbserver; does the target still stop on events?

> I think an existing simple remote target either:
> 	close / continue
> 		- target allowed to run but not detached
> 	close / none
> 		- target still attached but not resumed
> 
> 
> ``restart'' is something of a peverted form of run/continue.  The 
> program eventually stops again.  Another way of handling it is:
> 
> 	(gdb) monitor restart
> 	-> qRcmd ``restart''
> 	<- T<stop packet>

Sure.

> >Now let's consider our friend the hypothetical all-singing all-dancing
> >remote process agent.  I think we've concluded that we want
> >"run"/"kill"/"attach"/"detach" to behave as with native debugging.  We
> >also need a couple of other commands:
> > - Disconnect from the agent, leaving it in its current state, waiting
> >   for a new client
> > - Terminate the agent
> >
> >Terminating the agent can be a monitor command.  I like the idea of a
> >"disconnect" command.
> 
> Either a monitor command or an agent option.  Exit on disconnect.

Not sure what you mean to say here.  I want a way to close the
connection opened by "target", non-destructively, however.

> >One other thorny issue becomes what to do when the user quits or closes
> >the remote target etc.  Right now GDB offers the "kill" prompt as I
> >showed above.  For extended-remote that doesn't make a lot of sense to
> >me... I think that either "disconnect" or a "kill"/"terminate" sequence
> >makes more sense.  Thoughts?
> 
> The sequence is:
> 
> (gdb) attach 20856
> Attaching to program: /home/scratch/GDB/native/gdb/gdb, process 20856
> 0x41b44a04 in ?? ()
> (gdb) target core gdb.core
> A program is being debugged already.  Kill it? (y or n)
> 
> In certain situtations, yes that message doesn't make sense.  The 
> default [y] should still be to do something pretty fatal though. 
> Perhaphs suggest ``detaching'' first.

The think is, now it uses kill.  Kill would not close the agent
session, which is obviously not the desired behavior.  If you want it
to kill the agent (I think this is reasonable!) then there needs to be
a command for it other than the ``monitor'' odds-and-ends command, so
that extended-remote targets will have some obligation to know what to
do when they receive the kill message.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: ``detach remote''

[Daniel Jacobowitz]

On Sun, Aug 11, 2002 at 02:34:48PM -0400, Daniel Jacobowitz wrote:
> > >One other thorny issue becomes what to do when the user quits or closes
> > >the remote target etc.  Right now GDB offers the "kill" prompt as I
> > >showed above.  For extended-remote that doesn't make a lot of sense to
> > >me... I think that either "disconnect" or a "kill"/"terminate" sequence
> > >makes more sense.  Thoughts?
> > 
> > The sequence is:
> > 
> > (gdb) attach 20856
> > Attaching to program: /home/scratch/GDB/native/gdb/gdb, process 20856
> > 0x41b44a04 in ?? ()
> > (gdb) target core gdb.core
> > A program is being debugged already.  Kill it? (y or n)
> > 
> > In certain situtations, yes that message doesn't make sense.  The 
> > default [y] should still be to do something pretty fatal though. 
> > Perhaphs suggest ``detaching'' first.
> 
> The think is, now it uses kill.  Kill would not close the agent
> session, which is obviously not the desired behavior.  If you want it
> to kill the agent (I think this is reasonable!) then there needs to be
> a command for it other than the ``monitor'' odds-and-ends command, so
> that extended-remote targets will have some obligation to know what to
> do when they receive the kill message.

This whole question put another way:
  Obviously, if you start something with "run", you want to end it with
"kill".

  Obviously, if you start something with "attach", you want to end it
with "detach".

[These are not hard and fast, of course.  You can detach a run process
or kill an attached process.  But you surely see what I mean - they're
logical opposites.]

  If you start something with "target", how do you end it?  I propose
"disconnect".


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: ``detach remote''

[Andrew Cagney]

> This whole question put another way:
>   Obviously, if you start something with "run", you want to end it with
> "kill".
> 
>   Obviously, if you start something with "attach", you want to end it
> with "detach".
> 
> [These are not hard and fast, of course.  You can detach a run process
> or kill an attached process.  But you surely see what I mean - they're
> logical opposites.]

True,

There is a tradeoff between convenience and modal behavour.  Need a user 
survey (however, I suspect the attach/detach argument would win :-).

>   If you start something with "target", how do you end it?  I propose
> "disconnect".

The user doesn't start something with target, they ``connect'' using 
target.  That should more strongly suggest that ``disconnect'' 
disconnects the connection :-)

The doco will end up needing a glossary.

Andrew

Re: RFC: ``detach remote''

[Daniel Jacobowitz]

On Mon, Aug 12, 2002 at 10:36:48AM -0400, Andrew Cagney wrote:
> 
> >This whole question put another way:
> >  Obviously, if you start something with "run", you want to end it with
> >"kill".
> >
> >  Obviously, if you start something with "attach", you want to end it
> >with "detach".
> >
> >[These are not hard and fast, of course.  You can detach a run process
> >or kill an attached process.  But you surely see what I mean - they're
> >logical opposites.]
> 
> True,
> 
> There is a tradeoff between convenience and modal behavour.  Need a user 
> survey (however, I suspect the attach/detach argument would win :-).

Actually, I took a couple of surveys about this.  Couldn't find
terribly many people to poll, but the general idea of having the target
resume on detach went over well.

> >  If you start something with "target", how do you end it?  I propose
> >"disconnect".
> 
> The user doesn't start something with target, they ``connect'' using 
> target.  That should more strongly suggest that ``disconnect'' 
> disconnects the connection :-)

Pity the command is "target" instead of "connect", then :)  It would
make the pairings clearer.

> The doco will end up needing a glossary.

So true...

What I think I'll do is submit a patch to add the "disconnect" command,
and then commit a patch to make gdbserver detach or resume the target
on a "D" (detach) packet.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: ``detach remote''

[Eli Zaretskii]

> Date: Mon, 12 Aug 2002 10:36:48 -0400
> From: Andrew Cagney <ac131313@ges.redhat.com>
> 
> The doco will end up needing a glossary.

Which isn't a bad idea at all, IMHO.

Re: RFC: ``detach remote''

[Daniel Jacobowitz]

On Mon, Aug 12, 2002 at 10:47:26AM -0400, Daniel Jacobowitz wrote:
> On Mon, Aug 12, 2002 at 10:36:48AM -0400, Andrew Cagney wrote:
> > 
> > >This whole question put another way:
> > >  Obviously, if you start something with "run", you want to end it with
> > >"kill".
> > >
> > >  Obviously, if you start something with "attach", you want to end it
> > >with "detach".
> > >
> > >[These are not hard and fast, of course.  You can detach a run process
> > >or kill an attached process.  But you surely see what I mean - they're
> > >logical opposites.]
> > 
> > True,
> > 
> > There is a tradeoff between convenience and modal behavour.  Need a user 
> > survey (however, I suspect the attach/detach argument would win :-).
> 
> Actually, I took a couple of surveys about this.  Couldn't find
> terribly many people to poll, but the general idea of having the target
> resume on detach went over well.
> 
> > >  If you start something with "target", how do you end it?  I propose
> > >"disconnect".
> > 
> > The user doesn't start something with target, they ``connect'' using 
> > target.  That should more strongly suggest that ``disconnect'' 
> > disconnects the connection :-)
> 
> Pity the command is "target" instead of "connect", then :)  It would
> make the pairings clearer.
> 
> > The doco will end up needing a glossary.
> 
> So true...
> 
> What I think I'll do is submit a patch to add the "disconnect" command,
> and then commit a patch to make gdbserver detach or resume the target
> on a "D" (detach) packet.

So I did this, and I really like the result.  Here's the gdb side of
the patch.  It adds a command, ``disconnect'', with a new target
method.  The command only works for target remote (and friends), and
disconnects without sending the "D" packet.  Then I modify gdbserver to
handle the "D" packet correctly.  How does this look?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-08-29  Daniel Jacobowitz  <drow@mvista.com>

	* NEWS: Mention gdbserver detach change and ``disconnect'' command.
	* infcmd.c (disconnect_command): New function.
	(_initialize_infcmd): Add ``disconnect'' command.
	* remote.c (remote_async_detach): Delete.
	(remote_detach): Merge remote_async_detach.
	(remote_disconnect): New.
	(init_remote_ops): Set to_disconnect.
	(init_remote_cisco_ops): Likewise.
	(init_remote_async_ops): Likewise.  Use remote_detach.
	* target.c (cleanup_target): Default to_disconnect.
	(update_current_target): Inherit to_disconnect.
	(target_disconnect, debug_to_disconnect): New functions.
	(setup_target_debug): Set to_disconnect.
	* target.h (struct target_ops): Add to_disconnect.
	(target_disconnect): Add prototype.

2002-08-29  Daniel Jacobowitz  <drow@mvista.com>

	* gdb.texinfo: Document ``disconnect'' command.

2002-08-29  Daniel Jacobowitz  <drow@mvista.com>

	* mi-cmds.c (mi_cmds): Add ``-target-disconnect''.
	* gdbmi.texinfo: Document ``-target-disconnect''.

Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.90
diff -u -p -r1.90 NEWS
--- NEWS	22 Aug 2002 21:52:44 -0000	1.90
+++ NEWS	29 Aug 2002 19:38:39 -0000
@@ -3,6 +3,12 @@
 
 *** Changes since GDB 5.2:
 
+* The meaning of ``detach'' has changed for gdbserver
+
+The ``detach'' command will now resume the application, as documented.  To
+disconnect from gdbserver and leave it stopped, use the new ``disconnect''
+command.
+
 * ``gdbserver'' now supports multi-threaded applications on some targets
 
 Support for debugging multi-threaded applications which use  
Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.54
diff -u -p -r1.54 infcmd.c
--- infcmd.c	21 Aug 2002 16:34:09 -0000	1.54
+++ infcmd.c	29 Aug 2002 19:38:39 -0000
@@ -72,6 +72,8 @@ static void float_info (char *, int);
 
 static void detach_command (char *, int);
 
+static void disconnect_command (char *, int);
+
 static void interrupt_target_command (char *args, int from_tty);
 
 static void unset_environment_command (char *, int);
@@ -1889,6 +1891,26 @@ detach_command (char *args, int from_tty
     detach_hook ();
 }
 
+/* Disconnect from the current target without resuming it (leaving it
+   waiting for a debugger).
+
+   We'd better not have left any breakpoints in the program or the
+   next debugger will get confused.  Currently only supported for some
+   remote targets, since the normal attach mechanisms don't work on
+   stopped processes on some native platforms (e.g. GNU/Linux).  */
+
+static void
+disconnect_command (char *args, int from_tty)
+{
+  dont_repeat ();		/* Not for the faint of heart */
+  target_disconnect (args, from_tty);
+#if defined(SOLIB_RESTART)
+  SOLIB_RESTART ();
+#endif
+  if (detach_hook)
+    detach_hook ();
+}
+
 /* Stop the execution of the target while running in async mode, in
    the backgound. */
 
@@ -2040,6 +2062,11 @@ to specify the program, and to load its 
 	   "Detach a process or file previously attached.\n\
 If a process, it is no longer traced, and it continues its execution.  If\n\
 you were debugging a file, the file is closed and gdb no longer accesses it.");
+
+  add_com ("disconnect", class_run, disconnect_command,
+	   "Disconnect from a target.\n\
+The target will wait for another debugger to connect.  Not available for\n\
+all targets.");
 
   add_com ("signal", class_run, signal_command,
 	   "Continue program giving it signal specified by the argument.\n\
Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.93
diff -u -p -r1.93 remote.c
--- remote.c	18 Aug 2002 23:17:57 -0000	1.93
+++ remote.c	29 Aug 2002 19:38:41 -0000
@@ -128,7 +128,6 @@ static void remote_async_kill (void);
 static int tohex (int nib);
 
 static void remote_detach (char *args, int from_tty);
-static void remote_async_detach (char *args, int from_tty);
 
 static void remote_interrupt (int signo);
 
@@ -2415,15 +2414,19 @@ remote_detach (char *args, int from_tty)
   strcpy (buf, "D");
   remote_send (buf, (rs->remote_packet_size));
 
+  /* Unregister the file descriptor from the event loop. */
+  if (target_is_async_p ())
+    serial_async (remote_desc, NULL, 0);
+
   target_mourn_inferior ();
   if (from_tty)
     puts_filtered ("Ending remote debugging.\n");
-
 }
 
-/* Same as remote_detach, but with async support. */
+/* Same as remote_detach, but don't send the "D" packet; just disconnect.  */
+
 static void
-remote_async_detach (char *args, int from_tty)
+remote_disconnect (char *args, int from_tty)
 {
   struct remote_state *rs = get_remote_state ();
   char *buf = alloca (rs->remote_packet_size);
@@ -2431,10 +2434,6 @@ remote_async_detach (char *args, int fro
   if (args)
     error ("Argument given to \"detach\" when remotely debugging.");
 
-  /* Tell the remote target to detach.  */
-  strcpy (buf, "D");
-  remote_send (buf, (rs->remote_packet_size));
-
   /* Unregister the file descriptor from the event loop. */
   if (target_is_async_p ())
     serial_async (remote_desc, NULL, 0);
@@ -5414,6 +5413,7 @@ Specify the serial device it is connecte
   remote_ops.to_open = remote_open;
   remote_ops.to_close = remote_close;
   remote_ops.to_detach = remote_detach;
+  remote_ops.to_disconnect = remote_disconnect;
   remote_ops.to_resume = remote_resume;
   remote_ops.to_wait = remote_wait;
   remote_ops.to_fetch_registers = remote_fetch_registers;
@@ -5837,6 +5837,7 @@
   remote_cisco_ops.to_open = remote_cisco_open;
   remote_cisco_ops.to_close = remote_cisco_close;
   remote_cisco_ops.to_detach = remote_detach;
+  remote_cisco_ops.to_disconnect = remote_disconnect;
   remote_cisco_ops.to_resume = remote_resume;
   remote_cisco_ops.to_wait = remote_cisco_wait;
   remote_cisco_ops.to_fetch_registers = remote_fetch_registers;
@@ -5932,7 +5933,8 @@ init_remote_async_ops (void)
 Specify the serial device it is connected to (e.g. /dev/ttya).";
   remote_async_ops.to_open = remote_async_open;
   remote_async_ops.to_close = remote_close;
-  remote_async_ops.to_detach = remote_async_detach;
+  remote_async_ops.to_detach = remote_detach;
+  remote_async_ops.to_disconnect = remote_disconnect;
   remote_async_ops.to_resume = remote_async_resume;
   remote_async_ops.to_wait = remote_async_wait;
   remote_async_ops.to_fetch_registers = remote_fetch_registers;
Index: target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.40
diff -u -p -r1.40 target.c
--- target.c	26 Aug 2002 19:18:33 -0000	1.40
+++ target.c	29 Aug 2002 19:38:41 -0000
@@ -384,6 +384,9 @@ cleanup_target (struct target_ops *t)
   de_fault (to_require_detach, 
 	    (void (*) (int, char *, int)) 
 	    target_ignore);
+  de_fault (to_disconnect, 
+	    (void (*) (char *, int)) 
+	    tcomplain);
   de_fault (to_resume, 
 	    (void (*) (ptid_t, int, enum target_signal)) 
 	    noprocess);
@@ -591,6 +594,7 @@ update_current_target (void)
       INHERIT (to_require_attach, t);
       INHERIT (to_detach, t);
       INHERIT (to_require_detach, t);
+      INHERIT (to_disconnect, t);
       INHERIT (to_resume, t);
       INHERIT (to_wait, t);
       INHERIT (to_post_wait, t);
@@ -1182,6 +1186,16 @@ target_detach (char *args, int from_tty)
 }
 
 void
+target_disconnect (char *args, int from_tty)
+{
+  /* Handle any optimized stores to the inferior.  */
+#ifdef DO_DEFERRED_STORES
+  DO_DEFERRED_STORES;
+#endif
+  (current_target.to_disconnect) (args, from_tty);
+}
+
+void
 target_link (char *modname, CORE_ADDR *t_reloc)
 {
   if (STREQ (current_target.to_shortname, "rombug"))
@@ -1654,6 +1668,15 @@ debug_to_require_detach (int pid, char *
 }
 
 static void
+debug_to_disconnect (char *args, int from_tty)
+{
+  debug_target.to_disconnect (args, from_tty);
+
+  fprintf_unfiltered (gdb_stdlog, "target_disconnect (%s, %d)\n",
+		      args, from_tty);
+}
+
+static void
 debug_to_resume (ptid_t ptid, int step, enum target_signal siggnal)
 {
   debug_target.to_resume (ptid, step, siggnal);
@@ -2397,6 +2420,7 @@ setup_target_debug (void)
   current_target.to_require_attach = debug_to_require_attach;
   current_target.to_detach = debug_to_detach;
   current_target.to_require_detach = debug_to_require_detach;
+  current_target.to_disconnect = debug_to_disconnect;
   current_target.to_resume = debug_to_resume;
   current_target.to_wait = debug_to_wait;
   current_target.to_post_wait = debug_to_post_wait;
Index: target.h
===================================================================
RCS file: /cvs/src/src/gdb/target.h,v
retrieving revision 1.26
diff -u -p -r1.26 target.h
--- target.h	26 Aug 2002 19:18:33 -0000	1.26
+++ target.h	29 Aug 2002 19:38:41 -0000
@@ -196,6 +196,7 @@ struct target_ops
     void (*to_require_attach) (char *, int);
     void (*to_detach) (char *, int);
     void (*to_require_detach) (int, char *, int);
+    void (*to_disconnect) (char *, int);
     void (*to_resume) (ptid_t, int, enum target_signal);
     ptid_t (*to_wait) (ptid_t, struct target_waitstatus *);
     void (*to_post_wait) (ptid_t, int);
@@ -435,6 +436,11 @@ extern void target_detach (char *, int);
 
 #define target_require_detach(pid, args, from_tty)	\
      (*current_target.to_require_detach) (pid, args, from_tty)
+
+/* Disconnect from the current target without resuming it (leaving it
+   waiting for a debugger).  */
+
+extern void target_disconnect (char *, int);
 
 /* Resume execution of the target process PTID.  STEP says whether to
    single-step or to run free; SIGGNAL is the signal to be given to
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.115
diff -u -p -r1.115 gdb.texinfo
--- doc/gdb.texinfo	25 Aug 2002 19:10:15 -0000	1.115
+++ doc/gdb.texinfo	29 Aug 2002 19:38:46 -0000
@@ -10802,6 +10802,9 @@ step and continue the remote program.
 To resume the remote program and stop debugging it, use the @code{detach}
 command.
 
+To disconnect from the remote program and let it wait for another debugger
+to connect, use the @code{disconnect} command.
+
 @cindex interrupting remote programs
 @cindex remote programs, interrupting
 Whenever @value{GDBN} is waiting for the remote program, if you type the
@@ -14440,7 +14443,7 @@ Toggle debug flag.
 @cindex @code{D} packet
 
 Detach @value{GDBN} from the remote system.  Sent to the remote target
-before @value{GDBN} disconnects.
+before @value{GDBN} disconnects via the @code{detach} command.
 
 Reply:
 @table @samp
Index: mi/gdbmi.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/mi/gdbmi.texinfo,v
retrieving revision 1.27
diff -u -p -r1.27 gdbmi.texinfo
--- mi/gdbmi.texinfo	17 Jun 2002 17:30:57 -0000	1.27
+++ mi/gdbmi.texinfo	29 Aug 2002 19:38:47 -0000
@@ -3109,6 +3109,31 @@ The corresponding @value{GDBN} command i
 @end smallexample
 
 
+@subheading The @code{-target-disconnect} Command
+@findex -target-disconnect
+
+@subsubheading Synopsis
+
+@example
+ -target-disconnect
+@end example
+
+Disconnect from the remote target.  There's no output.
+
+@subsubheading @value{GDBN} command
+
+The corresponding @value{GDBN} command is @samp{disconnect}.
+
+@subsubheading Example
+
+@smallexample
+(@value{GDBP})
+-target-disconnect
+^done
+(@value{GDBP})
+@end smallexample
+
+
 @subheading The @code{-target-download} Command
 @findex -target-download
 
Index: mi/mi-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.c,v
retrieving revision 1.8
diff -u -p -r1.8 mi-cmds.c
--- mi/mi-cmds.c	6 Mar 2001 08:21:45 -0000	1.8
+++ mi/mi-cmds.c	29 Aug 2002 19:38:47 -0000
@@ -122,6 +122,7 @@ struct mi_cmd mi_cmds[] =
   {"target-attach", 0, 0},
   {"target-compare-sections", 0, 0},
   {"target-detach", "detach", 0},
+  {"target-disconnect", "disconnect", 0},
   {"target-download", 0, mi_cmd_target_download},
   {"target-exec-status", 0, 0},
   {"target-list-available-targets", 0, 0},

Re: RFC: ``detach remote''

[Andrew Cagney]

> 2002-08-29  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* mi-cmds.c (mi_cmds): Add ``-target-disconnect''.
> 	* gdbmi.texinfo: Document ``-target-disconnect''.

For MI, it needs a test case.  It might as well accept both ``command 
not for this target'' and ``success'.  I think people often first write 
the test case and then use the trace output to finish the doco.

> 2002-08-29  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* gdb.texinfo: Document ``disconnect'' command.

(under which node? C-X 4 a normally includes that).

Eli will likely have more pointers. I think at least a ``@kindex 
disconnect'' entry.

(I think hold this one for 5.3, at least for the moment),
Andrew

Re: RFC: ``detach remote''

[Daniel Jacobowitz]

On Tue, Sep 03, 2002 at 05:32:54PM -0400, Andrew Cagney wrote:
> >2002-08-29  Daniel Jacobowitz  <drow@mvista.com>
> >
> >	* mi-cmds.c (mi_cmds): Add ``-target-disconnect''.
> >	* gdbmi.texinfo: Document ``-target-disconnect''.
> 
> For MI, it needs a test case.  It might as well accept both ``command 
> not for this target'' and ``success'.  I think people often first write 
> the test case and then use the trace output to finish the doco.

OK.  I haven't looked at that part of the MI testsuite so I'll have to
come back to this when I have a little time.

> >2002-08-29  Daniel Jacobowitz  <drow@mvista.com>
> >
> >	* gdb.texinfo: Document ``disconnect'' command.
> 
> (under which node? C-X 4 a normally includes that).

I don't use emacs to write ChangeLog entries, I find changelog-mode too
unintuitive.

> Eli will likely have more pointers. I think at least a ``@kindex 
> disconnect'' entry.
> 
> (I think hold this one for 5.3, at least for the moment),

OK; I'd like to see it in 5.3 but if you think it's too new then it can
wait.  Sounds like you're OK with the command syntax, which is what I
really wanted to establish.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: ``detach remote''

[Eli Zaretskii]

On Tue, 3 Sep 2002, Andrew Cagney wrote:

> Eli will likely have more pointers. I think at least a ``@kindex 
> disconnect'' entry.

I think I've missed that patch.  I will look it up in the archives and 
review it ASAP.  Thanks for the heads-up.

Re: RFC: ``detach remote''

[Eli Zaretskii]

On Tue, 3 Sep 2002, Daniel Jacobowitz wrote:

> > >	* gdb.texinfo: Document ``disconnect'' command.
> > 
> > (under which node? C-X 4 a normally includes that).
> 
> I don't use emacs to write ChangeLog entries, I find changelog-mode too
> unintuitive.

In what version of Emacs?  Latest versions 21.x have many improvements, 
but I found changelog-mode very useful even before that.  Perhaps you 
might consider telling your reservations on emacs-devel@gnu.org.

Re: RFC: ``detach remote''

[Eli Zaretskii]

On Tue, 3 Sep 2002, Andrew Cagney wrote:

> > 	* gdb.texinfo: Document ``disconnect'' command.
> 
> (under which node? C-X 4 a normally includes that).
> 
> Eli will likely have more pointers. I think at least a ``@kindex 
> disconnect'' entry.

Yes, please add the @kindex entry.

I don't have any other comments on this patch, it's okay with me.