tracing broken if target doesn't do disconnected tracing

[Pedro Alves <pedro@codesourcery.com>]

The gdbserver tracepoints patch I just posted doesn't
include disconnected tracing yet.  Note what
happens then:

 (gdb) tar remote :9999
 Remote debugging using :9999
 Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.10.1.so...done.
 done.
 Loaded symbols for /lib64/ld-linux-x86-64.so.2
 0x00007f62e8519af0 in _start () from /lib64/ld-linux-x86-64.so.2
 (gdb) trace main
 Tracepoint 1 at 0x400640: file threads.c, line 35.
 (gdb) tstart
 Target does not support this command.

Taking a closer look, here's the problem:

 (gdb) set debug remote 1
 (gdb) tstart
 Sending packet: $QTinit#59...Packet received: OK
 Sending packet: $QTDP:1:0000000000400640:E:0:0#3f...Packet received: OK
 Sending packet: $QTDPsrc:1:400640:at:0:4:6d61696e#80...Packet received: OK
 Sending packet: $QTro:0000000000400200,000000000040021c:000000000040021c,000000000040023c:0000000000400240,0000000000400278:0000000000400278,0000000000400294:0000000000400298,0000000000400370:0000000000400370,00000000004003fc:00000000004003fc,000000000040040e:0000000000400410,0000000000400450:0000000000400450,0000000000400468:0000000000400468,00000000004004f8:00000000004004f8,0000000000400510:0000000000400510,0000000000400580:0000000000400580,0000000000400868:0000000000400868,0000000000400876:0000000000400878,000000000040087c:000000000040087c,00000000004008b0:00000000004008b0,00000000004009a4#5c...Packet received: OK
 Sending packet: $QTDisconnected:0#e2...Packet received:
 Target does not support this command.
 (gdb)

Below's the patch I'm using to get around this.

You'll still see GDB offering to leave the
trace running after disconnecting:

 ...
 (gdb) trace main
 Tracepoint 1 at 0x400640: file threads.c, line 35.
 (gdb) tstart
 (gdb) detach
 Trace is running.  Continue tracing after detach? (y or n) y
 warning: Target does not support disconnected tracing.
 Ending remote debugging.
 (gdb)

This is because common code outside remote.c has no clue
whether the target supports or not disconnected tracing, and
just assumes it does.  Exposing that property seems to
conflict a bit with the desire to allow
"set disconnected-tracing on" before actually being connected,
so, I've avoided doing it so far.  Maybe we could get away with
a tristate "yes|no|not-known-yet-maybe".

WDYT?  Shall I proceed with this as is?  Would you like to
address this?

-- 
Pedro Alves

2010-04-05  Pedro Alves  <pedro@codesourcery.com>

	gdb/
	* remote.c (remote_set_disconnected_tracing): Only set
	QTDisconnected if the remote end supports disconnected tracing.
	Warn otherwise, if trying to enable disconnected tracing.

---
 gdb/remote.c |   15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

Index: src/gdb/remote.c
===================================================================
--- src.orig/gdb/remote.c	2010-04-04 23:55:38.000000000 +0100
+++ src/gdb/remote.c	2010-04-05 00:40:57.000000000 +0100
@@ -9776,11 +9776,16 @@ remote_set_disconnected_tracing (int val
 {
   struct remote_state *rs = get_remote_state ();
 
-  sprintf (rs->buf, "QTDisconnected:%x", val);
-  putpkt (rs->buf);
-  remote_get_noisy_reply (&target_buf, &target_buf_size);
-  if (strcmp (target_buf, "OK"))
-    error (_("Target does not support this command."));
+  if (rs->disconnected_tracing)
+    {
+      sprintf (rs->buf, "QTDisconnected:%x", val);
+      putpkt (rs->buf);
+      remote_get_noisy_reply (&target_buf, &target_buf_size);
+      if (strcmp (target_buf, "OK"))
+	error (_("Target does not support this command."));
+    }
+  else if (val)
+    warning (_("Target does not support disconnected tracing."));
 }
 
 static int