RFA: "disconnect" command

RFA: "disconnect" command

[Daniel Jacobowitz]

This patch got tabled shortly before 5.3, due to bad timing on my part. 
Now here we are coming up on 6.0 and my timing's no better... this is
the first of several old patches that I would like to see included in
6.0, assuming I get the time to revisit them all.

Refresher on this one: the patch adds a "disconnect" commad, and
implements it for remote targets.  "disconnect" leaves the target
stopped, while "detach" usually resumes it.  Useful with kgdb,
gdbserver, et cetera.

I've included the gdbserver portion of the patch this time, too.

There was a consensus on this patch the last time I posted it, but it's
been so long that I'd like a thumbs-up from another maintainer first.
I've corrected the doc problems; Andrew, there's still no MI testcase,
because I could not figure out a reasonable way to write one without
leaving a dangling process around.  Re-attaching to it to kill it
properly, from within the testsuite, ranges from hard to really hard.

Thoughts?  OK?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-06-14  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.

2003-06-14  Daniel Jacobowitz  <drow@mvista.com>

	* linux-low.c: Move comment to linux_thread_alive where it belonged.
	(linux_detach_one_process, linux_detach): New functions.
	(linux_target_ops): Add linux_detach.
	* server.c (main): Handle 'D' packet.
	* target.h (struct target_ops): Add "detach" member.
	(detach_inferior): Define.

2003-06-14  Daniel Jacobowitz  <drow@mvista.com>

        * gdb.texinfo (Debug Session): Document "disconnect" command.
	(GDB/MI Target Manipulation): Document "-target-disconnect".

2003-06-14  Daniel Jacobowitz  <drow@mvista.com>

        * mi-cmds.c (mi_cmds): Add "-target-disconnect".


Index: gdb/NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.109
diff -u -p -r1.109 NEWS
--- gdb/NEWS	13 May 2003 05:40:34 -0000	1.109
+++ gdb/NEWS	14 Jun 2003 04:05:25 -0000
@@ -3,6 +3,12 @@
 
 *** Changes since GDB 5.3:
 
+* 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.
+
 * d10v `regs' command deprecated
 
 The `info registers' command has been updated so that it displays the
Index: gdb/infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.81
diff -u -p -r1.81 infcmd.c
--- gdb/infcmd.c	11 Jun 2003 19:38:26 -0000	1.81
+++ gdb/infcmd.c	14 Jun 2003 04:05:25 -0000
@@ -81,6 +81,8 @@ static void float_info (char *, int);
 
 static void detach_command (char *, int);
 
+static void disconnect_command (char *, int);
+
 static void unset_environment_command (char *, int);
 
 static void set_environment_command (char *, int);
@@ -1876,6 +1878,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. */
 void
@@ -2013,6 +2035,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: gdb/remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.105
diff -u -p -r1.105 remote.c
--- gdb/remote.c	10 Jun 2003 14:37:04 -0000	1.105
+++ gdb/remote.c	14 Jun 2003 04:05:26 -0000
@@ -126,7 +126,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);
 
@@ -2421,15 +2420,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);
@@ -2437,10 +2440,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);
@@ -5435,6 +5434,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;
@@ -5855,6 +5855,7 @@ Specify the serial device it is connecte
   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;
@@ -5950,7 +5951,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: gdb/target.c
===================================================================
RCS file: /cvs/src/src/gdb/target.c,v
retrieving revision 1.52
diff -u -p -r1.52 target.c
--- gdb/target.c	8 May 2003 20:52:48 -0000	1.52
+++ gdb/target.c	14 Jun 2003 04:05:26 -0000
@@ -95,6 +95,8 @@ static void debug_to_attach (char *, int
 
 static void debug_to_detach (char *, int);
 
+static void debug_to_disconnect (char *, int);
+
 static void debug_to_resume (ptid_t, int, enum target_signal);
 
 static ptid_t debug_to_wait (ptid_t, struct target_waitstatus *);
@@ -371,6 +373,9 @@ cleanup_target (struct target_ops *t)
   de_fault (to_detach, 
 	    (void (*) (char *, int)) 
 	    target_ignore);
+  de_fault (to_disconnect, 
+	    (void (*) (char *, int)) 
+	    tcomplain);
   de_fault (to_resume, 
 	    (void (*) (ptid_t, int, enum target_signal)) 
 	    noprocess);
@@ -556,6 +561,7 @@ update_current_target (void)
       INHERIT (to_attach, t);
       INHERIT (to_post_attach, t);
       INHERIT (to_detach, t);
+      INHERIT (to_disconnect, t);
       INHERIT (to_resume, t);
       INHERIT (to_wait, t);
       INHERIT (to_post_wait, t);
@@ -1141,6 +1147,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"))
@@ -1562,6 +1578,15 @@ debug_to_detach (char *args, int from_tt
 }
 
 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);
@@ -2202,6 +2227,7 @@ setup_target_debug (void)
   current_target.to_attach = debug_to_attach;
   current_target.to_post_attach = debug_to_post_attach;
   current_target.to_detach = debug_to_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: gdb/target.h
===================================================================
RCS file: /cvs/src/src/gdb/target.h,v
retrieving revision 1.40
diff -u -p -r1.40 target.h
--- gdb/target.h	2 Jun 2003 23:20:47 -0000	1.40
+++ gdb/target.h	14 Jun 2003 04:05:26 -0000
@@ -198,6 +198,7 @@ struct target_ops
     void (*to_attach) (char *, int);
     void (*to_post_attach) (int);
     void (*to_detach) (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);
@@ -413,6 +414,11 @@ extern struct target_stack_item *target_
    says whether to be verbose or not.  */
 
 extern void target_detach (char *, int);
+
+/* 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: gdb/doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.164
diff -u -p -r1.164 gdb.texinfo
--- gdb/doc/gdb.texinfo	9 Jun 2003 21:12:19 -0000	1.164
+++ gdb/doc/gdb.texinfo	14 Jun 2003 04:05:29 -0000
@@ -11069,6 +11069,10 @@ step and continue the remote program.
 To resume the remote program and stop debugging it, use the @code{detach}
 command.
 
+@kindex disconnect
+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
@@ -17392,6 +17396,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
 
@@ -19775,7 +19804,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: gdb/gdbserver/linux-low.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/linux-low.c,v
retrieving revision 1.23
diff -u -p -r1.23 linux-low.c
--- gdb/gdbserver/linux-low.c	5 Jun 2003 14:26:58 -0000	1.23
+++ gdb/gdbserver/linux-low.c	14 Jun 2003 04:05:29 -0000
@@ -234,13 +234,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)
 {
@@ -1249,6 +1264,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: gdb/gdbserver/server.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/server.c,v
retrieving revision 1.14
diff -u -p -r1.14 server.c
--- gdb/gdbserver/server.c	29 Aug 2002 18:50:25 -0000	1.14
+++ gdb/gdbserver/server.c	14 Jun 2003 04:05:29 -0000
@@ -217,6 +217,28 @@ main (int argc, char *argv[])
 	    case 'd':
 	      remote_debug = !remote_debug;
 	      break;
+	    case 'D':
+	      fprintf (stderr, "Detaching from inferior\n");
+	      detach_inferior ();
+	      write_ok (own_buf);
+	      putpkt (own_buf);
+	      remote_close ();		  
+
+	      /* If we are attached, then we can exit.  Otherwise, we need to
+		 hang around doing nothing, until the child is gone.  */
+	      if (!attached)
+		{
+		  int status, ret;
+
+		  do {
+		    ret = waitpid (signal_pid, &status, 0);
+		    if (WIFEXITED (status) || WIFSIGNALED (status))
+		      break;
+		  } while (ret != -1 || errno != ECHILD);
+		}
+
+	      exit (0);
+
 	    case '!':
 	      if (attached == 0)
 		{
Index: gdb/gdbserver/target.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/target.h,v
retrieving revision 1.6
diff -u -p -r1.6 target.h
--- gdb/gdbserver/target.h	5 Jun 2003 14:26:58 -0000	1.6
+++ gdb/gdbserver/target.h	14 Jun 2003 04:05:29 -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);
@@ -121,6 +125,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)
Index: gdb/mi/mi-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/mi/mi-cmds.c,v
retrieving revision 1.12
diff -u -p -r1.12 mi-cmds.c
--- gdb/mi/mi-cmds.c	4 May 2003 03:50:13 -0000	1.12
+++ gdb/mi/mi-cmds.c	14 Jun 2003 04:05:29 -0000
@@ -127,6 +127,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: RFA: "disconnect" command

[Eli Zaretskii]

> Date: Sat, 14 Jun 2003 00:26:42 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> Refresher on this one: the patch adds a "disconnect" commad, and
> implements it for remote targets.  "disconnect" leaves the target
> stopped, while "detach" usually resumes it.  Useful with kgdb,
> gdbserver, et cetera.

The patch to gdb.texinfo is approved, but I think we should (a) tell
in the docs of `detach' that is usually resumes the target, and (b)
have an xref from `disconnect' to `detach'.

Re: RFA: "disconnect" command

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

 Daniel> This patch got tabled shortly before 5.3, due to bad timing
 Daniel> on my part. Now here we are coming up on 6.0 and my timing's
 Daniel> no better... this is the first of several old patches that I
 Daniel> would like to see included in 6.0, assuming I get the time to
 Daniel> revisit them all.

 Daniel> Refresher on this one: the patch adds a "disconnect" commad,
 Daniel> and implements it for remote targets.  "disconnect" leaves
 Daniel> the target stopped, while "detach" usually resumes it.
 Daniel> Useful with kgdb, gdbserver, et cetera.

Useful indeed.  But there is nothing in the names "detach" and
"disconnect" that suggests how they differ.  Would it be possible to
have command names that are suggestive of their action?

     paul

Re: RFA: "disconnect" command

[Daniel Jacobowitz]

On Mon, Jun 16, 2003 at 09:29:42AM -0400, Paul Koning wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
>  Daniel> This patch got tabled shortly before 5.3, due to bad timing
>  Daniel> on my part. Now here we are coming up on 6.0 and my timing's
>  Daniel> no better... this is the first of several old patches that I
>  Daniel> would like to see included in 6.0, assuming I get the time to
>  Daniel> revisit them all.
> 
>  Daniel> Refresher on this one: the patch adds a "disconnect" commad,
>  Daniel> and implements it for remote targets.  "disconnect" leaves
>  Daniel> the target stopped, while "detach" usually resumes it.
>  Daniel> Useful with kgdb, gdbserver, et cetera.
> 
> Useful indeed.  But there is nothing in the names "detach" and
> "disconnect" that suggests how they differ.  Would it be possible to
> have command names that are suggestive of their action?

The last time I proposed this, we went back and forth for a week on
names and this was the best we could come up with.  Have you got a
better suggestion?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: "disconnect" command

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

 Daniel> On Mon, Jun 16, 2003 at 09:29:42AM -0400, Paul Koning wrote:
 >> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
 >> ...
 Daniel> Refresher on this one: the patch adds a "disconnect" commad,
 Daniel> and implements it for remote targets.  "disconnect" leaves
 Daniel> the target stopped, while "detach" usually resumes it.
 Daniel> Useful with kgdb, gdbserver, et cetera.
 >> Useful indeed.  But there is nothing in the names "detach" and
 >> "disconnect" that suggests how they differ.  Would it be possible
 >> to have command names that are suggestive of their action?

 Daniel> The last time I proposed this, we went back and forth for a
 Daniel> week on names and this was the best we could come up with.
 Daniel> Have you got a better suggestion?

Nothing really promising.  But how about doing this with an (optional)
argument on the "detach" command, e.g., "detach stop" and "detach go"
with the latter being the default?

     paul

Re: RFA: "disconnect" command

[Daniel Jacobowitz]

On Mon, Jun 16, 2003 at 10:01:16AM -0400, Paul Koning wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
>  Daniel> On Mon, Jun 16, 2003 at 09:29:42AM -0400, Paul Koning wrote:
>  >> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
>  >> ...
>  Daniel> Refresher on this one: the patch adds a "disconnect" commad,
>  Daniel> and implements it for remote targets.  "disconnect" leaves
>  Daniel> the target stopped, while "detach" usually resumes it.
>  Daniel> Useful with kgdb, gdbserver, et cetera.
>  >> Useful indeed.  But there is nothing in the names "detach" and
>  >> "disconnect" that suggests how they differ.  Would it be possible
>  >> to have command names that are suggestive of their action?
> 
>  Daniel> The last time I proposed this, we went back and forth for a
>  Daniel> week on names and this was the best we could come up with.
>  Daniel> Have you got a better suggestion?
> 
> Nothing really promising.  But how about doing this with an (optional)
> argument on the "detach" command, e.g., "detach stop" and "detach go"
> with the latter being the default?

That's similar to what I suggested originally, though it makes a little
more sense.  If other people like it I'll switch, but I don't really
think it's better than disconnect.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: "disconnect" command

[Andrew Cagney]

> On Mon, Jun 16, 2003 at 10:01:16AM -0400, Paul Koning wrote:
> 
>> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
>> 
>>  Daniel> On Mon, Jun 16, 2003 at 09:29:42AM -0400, Paul Koning wrote:
>>  >> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
>>  >> ...
>>  Daniel> Refresher on this one: the patch adds a "disconnect" commad,
>>  Daniel> and implements it for remote targets.  "disconnect" leaves
>>  Daniel> the target stopped, while "detach" usually resumes it.
>>  Daniel> Useful with kgdb, gdbserver, et cetera.
>>  >> Useful indeed.  But there is nothing in the names "detach" and
>>  >> "disconnect" that suggests how they differ.  Would it be possible
>>  >> to have command names that are suggestive of their action?
>> 
>>  Daniel> The last time I proposed this, we went back and forth for a
>>  Daniel> week on names and this was the best we could come up with.
>>  Daniel> Have you got a better suggestion?
>> 
>> Nothing really promising.  But how about doing this with an (optional)
>> argument on the "detach" command, e.g., "detach stop" and "detach go"
>> with the latter being the default?
> 
> 
> That's similar to what I suggested originally, though it makes a little
> more sense.  If other people like it I'll switch, but I don't really
> think it's better than disconnect.

There was:
	connect / disconnect
	attach / detach
as pairs.

Andrew

Re: RFA: "disconnect" command

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Mon, Jun 16, 2003 at 09:29:42AM -0400, Paul Koning wrote:
> > >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> >
> >  Daniel> This patch got tabled shortly before 5.3, due to bad timing
> >  Daniel> on my part. Now here we are coming up on 6.0 and my timing's
> >  Daniel> no better... this is the first of several old patches that I
> >  Daniel> would like to see included in 6.0, assuming I get the time to
> >  Daniel> revisit them all.
> >
> >  Daniel> Refresher on this one: the patch adds a "disconnect" commad,
> >  Daniel> and implements it for remote targets.  "disconnect" leaves
> >  Daniel> the target stopped, while "detach" usually resumes it.
> >  Daniel> Useful with kgdb, gdbserver, et cetera.
> >
> > Useful indeed.  But there is nothing in the names "detach" and
> > "disconnect" that suggests how they differ.  Would it be possible to
> > have command names that are suggestive of their action?
> 
> The last time I proposed this, we went back and forth for a week on
> names and this was the best we could come up with.  Have you got a
> better suggestion?

It seems we never converge on names.  ;-)  Especially new names
for existing commands.  If you change the name of detach, you will
have to keep the old name around.

"Detach" does suggest resume, if you're from a unix background.
"Disconnect" does not.  I suggest that these names are adequate.

Re: RFA: "disconnect" command

[Michael Snyder]

Andrew Cagney wrote:
> 
> > On Mon, Jun 16, 2003 at 10:01:16AM -0400, Paul Koning wrote:
> >
> >> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> >
> >>
> >>  Daniel> On Mon, Jun 16, 2003 at 09:29:42AM -0400, Paul Koning wrote:
> >>  >> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> >>  >> ...
> >>  Daniel> Refresher on this one: the patch adds a "disconnect" commad,
> >>  Daniel> and implements it for remote targets.  "disconnect" leaves
> >>  Daniel> the target stopped, while "detach" usually resumes it.
> >>  Daniel> Useful with kgdb, gdbserver, et cetera.
> >>  >> Useful indeed.  But there is nothing in the names "detach" and
> >>  >> "disconnect" that suggests how they differ.  Would it be possible
> >>  >> to have command names that are suggestive of their action?
> >>
> >>  Daniel> The last time I proposed this, we went back and forth for a
> >>  Daniel> week on names and this was the best we could come up with.
> >>  Daniel> Have you got a better suggestion?
> >>
> >> Nothing really promising.  But how about doing this with an (optional)
> >> argument on the "detach" command, e.g., "detach stop" and "detach go"
> >> with the latter being the default?
> >
> >
> > That's similar to what I suggested originally, though it makes a little
> > more sense.  If other people like it I'll switch, but I don't really
> > think it's better than disconnect.
> 
> There was:
>         connect / disconnect
>         attach / detach
> as pairs.

Argh.  But "connect" isn't really analogous to attach.
It's analogous to "target remote".

Re: RFA: "disconnect" command

[Daniel Jacobowitz]

On Mon, Jun 16, 2003 at 04:47:01PM -0700, Michael Snyder wrote:
> Andrew Cagney wrote:
> > 
> > > On Mon, Jun 16, 2003 at 10:01:16AM -0400, Paul Koning wrote:
> > >
> > >> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> > >
> > >>
> > >>  Daniel> On Mon, Jun 16, 2003 at 09:29:42AM -0400, Paul Koning wrote:
> > >>  >> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> > >>  >> ...
> > >>  Daniel> Refresher on this one: the patch adds a "disconnect" commad,
> > >>  Daniel> and implements it for remote targets.  "disconnect" leaves
> > >>  Daniel> the target stopped, while "detach" usually resumes it.
> > >>  Daniel> Useful with kgdb, gdbserver, et cetera.
> > >>  >> Useful indeed.  But there is nothing in the names "detach" and
> > >>  >> "disconnect" that suggests how they differ.  Would it be possible
> > >>  >> to have command names that are suggestive of their action?
> > >>
> > >>  Daniel> The last time I proposed this, we went back and forth for a
> > >>  Daniel> week on names and this was the best we could come up with.
> > >>  Daniel> Have you got a better suggestion?
> > >>
> > >> Nothing really promising.  But how about doing this with an (optional)
> > >> argument on the "detach" command, e.g., "detach stop" and "detach go"
> > >> with the latter being the default?
> > >
> > >
> > > That's similar to what I suggested originally, though it makes a little
> > > more sense.  If other people like it I'll switch, but I don't really
> > > think it's better than disconnect.
> > 
> > There was:
> >         connect / disconnect
> >         attach / detach
> > as pairs.
> 
> Argh.  But "connect" isn't really analogous to attach.
> It's analogous to "target remote".

Well, there is no "connect" - in fact "target remote" is paired with
disconnect.

Still open to better ideas on the naming; but either way I'd like to
commit this before another release goes by...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFA: "disconnect" command

[Andrew Cagney]

> On Mon, Jun 16, 2003 at 04:47:01PM -0700, Michael Snyder wrote:

>> > There was:
>> >         connect / disconnect
>> >         attach / detach
>> > as pairs.
> 
>> 
>> Argh.  But "connect" isn't really analogous to attach.
>> It's analogous to "target remote".
> 
> 
> Well, there is no "connect" - in fact "target remote" is paired with
> disconnect.
> 
> Still open to better ideas on the naming; but either way I'd like to
> commit this before another release goes by...

I've no intention of asking for a name change.  However, things to do 
one day does un-screwup ``target remote'' - that commands behavior is 
overloaded :-)

Andrew

Re: RFA: "disconnect" command

[Andrew Cagney]

> This patch got tabled shortly before 5.3, due to bad timing on my part. 
> Now here we are coming up on 6.0 and my timing's no better... this is
> the first of several old patches that I would like to see included in
> 6.0, assuming I get the time to revisit them all.
> 
> Refresher on this one: the patch adds a "disconnect" commad, and
> implements it for remote targets.  "disconnect" leaves the target
> stopped, while "detach" usually resumes it.  Useful with kgdb,
> gdbserver, et cetera.
> 
> I've included the gdbserver portion of the patch this time, too.
> 
> There was a consensus on this patch the last time I posted it, but it's
> been so long that I'd like a thumbs-up from another maintainer first.
> I've corrected the doc problems; Andrew, there's still no MI testcase,
> because I could not figure out a reasonable way to write one without
> leaving a dangling process around.  Re-attaching to it to kill it
> properly, from within the testsuite, ranges from hard to really hard.
> 
> Thoughts?  OK?

The code, yea.  Just check that part in.

The doco, though, does not belong in ``Implementing a remote stub'' :-( 
(the existing doco is scrambled).

Can you please insert at the start of that chapter a new section called:

	@section Connecting to a remote target

and then, from ``Using the gdbserver program'' and ``Using the 
gdbserv.nlm program'', replace ``On the GDB host machine'' with an @xfef 
to ``Connecting to a remote target''.  And move 7. on from 
``Implementing a remote stub'' to the new section.

Andrew

Re: RFA: "disconnect" command

[Daniel Jacobowitz]

On Tue, Jun 17, 2003 at 10:59:27AM -0400, Andrew Cagney wrote:
> >This patch got tabled shortly before 5.3, due to bad timing on my part. 
> >Now here we are coming up on 6.0 and my timing's no better... this is
> >the first of several old patches that I would like to see included in
> >6.0, assuming I get the time to revisit them all.
> >
> >Refresher on this one: the patch adds a "disconnect" commad, and
> >implements it for remote targets.  "disconnect" leaves the target
> >stopped, while "detach" usually resumes it.  Useful with kgdb,
> >gdbserver, et cetera.
> >
> >I've included the gdbserver portion of the patch this time, too.
> >
> >There was a consensus on this patch the last time I posted it, but it's
> >been so long that I'd like a thumbs-up from another maintainer first.
> >I've corrected the doc problems; Andrew, there's still no MI testcase,
> >because I could not figure out a reasonable way to write one without
> >leaving a dangling process around.  Re-attaching to it to kill it
> >properly, from within the testsuite, ranges from hard to really hard.
> >
> >Thoughts?  OK?
> 
> The code, yea.  Just check that part in.
> 
> The doco, though, does not belong in ``Implementing a remote stub'' :-( 
> (the existing doco is scrambled).

Yeah, it is.  I was trying to avoid rewriting it, but since you
asked...

Is this better?  Eli, I think I got the Texinfo and general structure
right, but I'd appreciate it if you'd look over this anyway.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-06-14  Daniel Jacobowitz  <drow@mvista.com>

        * gdb.texinfo (Remote Debugging): New section "Connecting to a
	remote target".  Document the "detach" and "disconnect" commands.
	(Server, Netware, Debug Session): Reference "Connecting to a
	remote target".
	(GDB/MI Target Manipulation): Document "-target-disconnect".

Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.164
diff -u -p -r1.164 gdb.texinfo
--- doc/gdb.texinfo	9 Jun 2003 21:12:19 -0000	1.164
+++ doc/gdb.texinfo	17 Jun 2003 21:55:22 -0000
@@ -10513,12 +10513,113 @@ is supported other than to try it.
 @chapter Debugging remote programs
 
 @menu
+* Connecting::                  Connecting to a remote target
 * Server::	                Using the gdbserver program
 * NetWare::                     Using the gdbserve.nlm program
 * Remote configuration::        Remote configuration
 * remote stub::                 Implementing a remote stub
 @end menu
 
+@node Connecting
+@section Connecting to a remote target
+
+On the @value{GDBN} host machine, you will need an unstripped copy of
+your program, since @value{GDBN} needs symobl and debugging information.
+Start up @value{GDBN} as usual, using the name of the local copy of your
+program as the first argument.
+
+@cindex serial line, @code{target remote}
+If you're using a serial line, you may want to give @value{GDBN} the
+@w{@samp{--baud}} option, or use the @code{set remotebaud} command
+before the @code{target} command.
+
+After that, use @code{target remote} to establish communications with
+the target machine.  Its argument specifies how to communicate---either
+via a devicename attached to a direct serial line, or a TCP or UDP port
+(possibly to a terminal server which in turn has a serial line to the
+target).  For example, to use a serial line connected to the device
+named @file{/dev/ttyb}:
+
+@smallexample
+target remote /dev/ttyb
+@end smallexample
+
+@cindex TCP port, @code{target remote}
+To use a TCP connection, use an argument of the form
+@code{@var{host}:@var{port}} or @code{tcp:@var{host}:@var{port}}.
+For example, to connect to port 2828 on a
+terminal server named @code{manyfarms}:
+
+@smallexample
+target remote manyfarms:2828
+@end smallexample
+
+If your remote target is actually running on the same machine as
+your debugger session (e.g.@: a simulator of your target running on
+the same host), you can omit the hostname.  For example, to connect
+to port 1234 on your local machine:
+
+@smallexample
+target remote :1234
+@end smallexample
+@noindent
+
+Note that the colon is still required here.
+
+@cindex UDP port, @code{target remote}
+To use a UDP connection, use an argument of the form
+@code{udp:@var{host}:@var{port}}.  For example, to connect to UDP port 2828
+on a terminal server named @code{manyfarms}:
+
+@smallexample
+target remote udp:manyfarms:2828
+@end smallexample
+
+When using a UDP connection for remote debugging, you should keep in mind
+that the `U' stands for ``Unreliable''.  UDP can silently drop packets on
+busy or unreliable networks, which will cause havoc with your debugging
+session.
+
+Now you can use all the usual commands to examine and change data and to
+step and continue the remote program.
+
+@cindex interrupting remote programs
+@cindex remote programs, interrupting
+Whenever @value{GDBN} is waiting for the remote program, if you type the
+interrupt character (often @key{C-C}), @value{GDBN} attempts to stop the
+program.  This may or may not succeed, depending in part on the hardware
+and the serial drivers the remote system uses.  If you type the
+interrupt character once again, @value{GDBN} displays this prompt:
+
+@smallexample
+Interrupted while waiting for the program.
+Give up (and stop debugging it)?  (y or n)
+@end smallexample
+
+If you type @kbd{y}, @value{GDBN} abandons the remote debugging session.
+(If you decide you want to try again later, you can use @samp{target
+remote} again to connect once more.)  If you type @kbd{n}, @value{GDBN}
+goes back to waiting.
+
+@table @code
+@kindex detach (remote)
+@item detach
+When you have finished debugging the remote program, you can use the
+@code{detach} command to release it from @value{GDBN} control.
+Detaching from the target normally resumes its execution, but the results
+will depend on your particular remote stub.  After the @code{detach}
+command, @value{GDBN} is free to connect to another target.
+
+@kindex disconnect
+@item disconnect
+The @code{disconnect} command behaves like @code{detach}, except that
+the target is generally not resumed.  It will wait for @value{GDBN}
+(this instance or another one) to connect and continue debugging.  When
+you have finished debugging the remote program, you can use the After
+the @code{disconnect} command, @value{GDBN} is again free to connect to
+another target.
+@end table
+
 @node Server
 @section Using the @code{gdbserver} program
 
@@ -10601,34 +10702,15 @@ target> gdbserver @var{comm} --attach @v
 @var{pid} is the process ID of a currently running process.  It isn't necessary
 to point @code{gdbserver} at a binary for the running process.
 
-@item On the @value{GDBN} host machine,
-you need an unstripped copy of your program, since @value{GDBN} needs
-symbols and debugging information.  Start up @value{GDBN} as usual,
-using the name of the local copy of your program as the first argument.
-(You may also need the @w{@samp{--baud}} option if the serial line is
-running at anything other than 9600@dmn{bps}.)  After that, use @code{target
-remote} to establish communications with @code{gdbserver}.  Its argument
-is either a device name (usually a serial device, like
-@file{/dev/ttyb}), or a TCP port descriptor in the form
-@code{@var{host}:@var{PORT}}.  For example:
-
-@smallexample
-(@value{GDBP}) target remote /dev/ttyb
-@end smallexample
-
-@noindent
-communicates with the server via serial line @file{/dev/ttyb}, and
-
-@smallexample
-(@value{GDBP}) target remote the-target:2345
-@end smallexample
-
-@noindent
-communicates via a TCP connection to port 2345 on host @w{@file{the-target}}.
+@item On the host machine,
+connect to your target (@pxref{Connecting,,Connecting to a remote target}).
 For TCP connections, you must start up @code{gdbserver} prior to using
 the @code{target remote} command.  Otherwise you may get an error whose
 text depends on the host system, but which usually looks something like
-@samp{Connection refused}.
+@samp{Connection refused}.  You don't need to use the @code{load}
+command in @value{GDBN} when using gdbserver, since the program is
+already on the target.
+
 @end table
 
 @node NetWare
@@ -10670,22 +10752,10 @@ using a 19200@dmn{bps} connection:
 load gdbserve BOARD=1 PORT=2 BAUD=19200 emacs foo.txt
 @end smallexample
 
-@item On the @value{GDBN} host machine,
-you need an unstripped copy of your program, since @value{GDBN} needs
-symbols and debugging information.  Start up @value{GDBN} as usual,
-using the name of the local copy of your program as the first argument.
-(You may also need the @w{@samp{--baud}} option if the serial line is
-running at anything other than 9600@dmn{bps}.  After that, use @code{target
-remote} to establish communications with @code{gdbserve.nlm}.  Its
-argument is a device name (usually a serial device, like
-@file{/dev/ttyb}).  For example:
-
-@smallexample
-(@value{GDBP}) target remote /dev/ttyb
-@end smallexample
+@item
+On the @value{GDBN} host machine, connect to your target (@pxref{Connecting,,
+Connecting to a remote target}).
 
-@noindent
-communications with the server via serial line @file{/dev/ttyb}.
 @end table
 
 @node Remote configuration
@@ -11007,87 +11077,11 @@ Download your program to your target mac
 whatever means the manufacturer provides), and start it.
 
 @item
-To start remote debugging, run @value{GDBN} on the host machine, and specify
-as an executable file the program that is running in the remote machine.
-This tells @value{GDBN} how to find your program's symbols and the contents
-of its pure text.
-
-@item
-@cindex serial line, @code{target remote}
-Establish communication using the @code{target remote} command.
-Its argument specifies how to communicate with the target
-machine---either via a devicename attached to a direct serial line, or a
-TCP or UDP port (usually to a terminal server which in turn has a serial line
-to the target).  For example, to use a serial line connected to the
-device named @file{/dev/ttyb}:
-
-@smallexample
-target remote /dev/ttyb
-@end smallexample
-
-@cindex TCP port, @code{target remote}
-To use a TCP connection, use an argument of the form
-@code{@var{host}:@var{port}} or @code{tcp:@var{host}:@var{port}}.
-For example, to connect to port 2828 on a
-terminal server named @code{manyfarms}:
-
-@smallexample
-target remote manyfarms:2828
-@end smallexample
-
-If your remote target is actually running on the same machine as
-your debugger session (e.g.@: a simulator of your target running on
-the same host), you can omit the hostname.  For example, to connect
-to port 1234 on your local machine:
-
-@smallexample
-target remote :1234
-@end smallexample
-@noindent
-
-Note that the colon is still required here.
-
-@cindex UDP port, @code{target remote}
-To use a UDP connection, use an argument of the form
-@code{udp:@var{host}:@var{port}}.  For example, to connect to UDP port 2828
-on a terminal server named @code{manyfarms}:
-
-@smallexample
-target remote udp:manyfarms:2828
-@end smallexample
-
-When using a UDP connection for remote debugging, you should keep in mind
-that the `U' stands for ``Unreliable''.  UDP can silently drop packets on
-busy or unreliable networks, which will cause havoc with your debugging
-session.
+Start @value{GDBN} on the host, and connect to the target
+(@pxref{Connecting,,Connecting to a remote target}).
 
 @end enumerate
 
-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.
-
-@cindex interrupting remote programs
-@cindex remote programs, interrupting
-Whenever @value{GDBN} is waiting for the remote program, if you type the
-interrupt character (often @key{C-C}), @value{GDBN} attempts to stop the
-program.  This may or may not succeed, depending in part on the hardware
-and the serial drivers the remote system uses.  If you type the
-interrupt character once again, @value{GDBN} displays this prompt:
-
-@smallexample
-Interrupted while waiting for the program.
-Give up (and stop debugging it)?  (y or n)
-@end smallexample
-
-If you type @kbd{y}, @value{GDBN} abandons the remote debugging session.
-(If you decide you want to try again later, you can use @samp{target
-remote} again to connect once more.)  If you type @kbd{n}, @value{GDBN}
-goes back to waiting.
-
-
 @node Configurations
 @chapter Configuration-Specific Information
 
@@ -17392,6 +17386,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
 
@@ -19775,7 +19794,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

Re: RFA: "disconnect" command

[Eli Zaretskii]

> Date: Tue, 17 Jun 2003 17:59:51 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> Eli, I think I got the Texinfo and general structure
> right, but I'd appreciate it if you'd look over this anyway.

It's approved and can go in.  Thanks.

>                                                                   When
> +you have finished debugging the remote program, you can use the After
> +the @code{disconnect} command, @value{GDBN} is again free to connect to
> +another target.

It sounds like some snafu happened here: these were probably two or
more sentences, and some words got deleted.

Re: RFA: "disconnect" command

[Andrew Cagney]

> Thoughts?  OK?
> 
>> 
>> The code, yea.  Just check that part in.
>> 
>> The doco, though, does not belong in ``Implementing a remote stub'' :-( 
>> (the existing doco is scrambled).
> 
> 
> Yeah, it is.  I was trying to avoid rewriting it, but since you
> asked...

> Is this better?

Honestly, and with out looking at the result.  It can't be worse :-)

> Eli, I think I got the Texinfo and general structure
> right, but I'd appreciate it if you'd look over this anyway.

Much better structure :-)

Andrew

Re: RFA: "disconnect" command

[Daniel Jacobowitz]

On Wed, Jun 18, 2003 at 01:24:35AM +0300, Eli Zaretskii wrote:
> > Date: Tue, 17 Jun 2003 17:59:51 -0400
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > Eli, I think I got the Texinfo and general structure
> > right, but I'd appreciate it if you'd look over this anyway.
> 
> It's approved and can go in.  Thanks.
> 
> >                                                                   When
> > +you have finished debugging the remote program, you can use the After
> > +the @code{disconnect} command, @value{GDBN} is again free to connect to
> > +another target.
> 
> It sounds like some snafu happened here: these were probably two or
> more sentences, and some words got deleted.

Actually I copied and pasted one more line than I meant to.  The first
half of that sentence should go away.

Thanks, checked in!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer