fix tracecmd.exp against extended-remote gdbserver

[Pedro Alves <palves at redhat dot com>]

gdb.trace/tracecmd.exp sets a fast tracepoint before explicitly running a
program (one gets started implicitly against regular target remote gdbserver), and then
gdbserver crashes:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000403839 in register_size (n=0) at ../../../src/gdb/gdbserver/regcache.c:292
292       return reg_defs[n].size / 8;
(gdb) bt
#0  0x0000000000403839 in register_size (n=0) at ../../../src/gdb/gdbserver/regcache.c:292
#1  0x000000000042d19c in x86_get_min_fast_tracepoint_insn_len () at ../../../src/gdb/gdbserver/linux-x86-low.c:1585
#2  0x0000000000428a0d in linux_get_min_fast_tracepoint_insn_len () at ../../../src/gdb/gdbserver/linux-low.c:4960
#3  0x0000000000417bc7 in cmd_qtminftpilen (packet=0x64f210 "qTMinFTPILen") at ../../../src/gdb/gdbserver/tracepoint.c:3732
#4  0x000000000041873f in handle_tracepoint_query (packet=0x64f210 "qTMinFTPILen") at ../../../src/gdb/gdbserver/tracepoint.c:4000
#5  0x000000000040aa3b in handle_query (own_buf=0x64f210 "qTMinFTPILen", packet_len=12, new_packet_len_p=0x7fffffffdbb8) at ../../../src/gdb/gdbserver/server.c:1811
#6  0x000000000040cb70 in process_serial_event () at ../../../src/gdb/gdbserver/server.c:2871
#7  0x000000000040dc12 in handle_serial_event (err=0, client_data=0x0) at ../../../src/gdb/gdbserver/server.c:3285
#8  0x0000000000412963 in handle_file_event (event_file_desc=8) at ../../../src/gdb/gdbserver/event-loop.c:489
#9  0x00000000004120f0 in process_event () at ../../../src/gdb/gdbserver/event-loop.c:244
#10 0x0000000000412eca in start_event_loop () at ../../../src/gdb/gdbserver/event-loop.c:607
#11 0x000000000040c9b0 in main (argc=3, argv=0x7fffffffde58) at ../../../src/gdb/gdbserver/server.c:2770

Considering multi-process, gdb needs to make sure it is querying to the
proper remote process for the minimum fast tracepoint instruction.  That implies that we
can only query the target when there's a process at all.  I'm still adding the guard
to gdbserver, to address the case of an older gdb connecting.

Tested on x86_64 Fedora 16.  Will apply in a bit.

2012-02-02  Pedro Alves  <palves@redhat.com>

	* gdbserver/tracepoint.c (cmd_qtminftpilen): Return 0 if there's
	no current inferior.

2012-02-02  Pedro Alves  <palves@redhat.com>

	* gdb/remote.c (remote_get_min_fast_tracepoint_insn_len): Return 0
	if the current inferior has no execution.  Make sure the current
	remote process matches gdb's current inferior.

---

 gdb/gdbserver/tracepoint.c |    7 +++++++
 gdb/remote.c               |    8 ++++++++
 2 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/gdb/gdbserver/tracepoint.c b/gdb/gdbserver/tracepoint.c
index 3dc0073..5c565fe 100644
--- a/gdb/gdbserver/tracepoint.c
+++ b/gdb/gdbserver/tracepoint.c
@@ -3729,6 +3729,13 @@ cmd_qtstmat (char *packet)
 static void
 cmd_qtminftpilen (char *packet)
 {
+  if (current_inferior == NULL)
+    {
+      /* Indicate that the minimum length is currently unknown.  */
+      strcpy (packet, "0");
+      return;
+    }
+
   sprintf (packet, "%x", target_get_min_fast_tracepoint_insn_len ());
 }

diff --git a/gdb/remote.c b/gdb/remote.c
index 1153980..1c37b69 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -10592,6 +10592,14 @@ remote_get_min_fast_tracepoint_insn_len (void)
   struct remote_state *rs = get_remote_state ();
   char *reply;

+  /* If we're not debugging a process yet, the IPA can't be
+     loaded.  */
+  if (!target_has_execution)
+    return 0;
+
+  /* Make sure the remote is pointing at the right process.  */
+  set_general_process ();
+
   sprintf (rs->buf, "qTMinFTPILen");
   putpkt (rs->buf);
   reply = remote_get_noisy_reply (&target_buf, &target_buf_size);

-- 
Pedro Alves