Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status

Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status

[Hui Zhu]

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

Hi Pedro,

After discussion with Yao in irc, our thought is if we want handle it in 
update_global_location_list, there will a lot of part need to be change, 
because there are a lot of call level.  For example:
#0  remote_download_tracepoint (loc=0x35040b0) at 
../../src/gdb/remote.c:9982
#1  0x00000000006727c1 in download_tracepoint_locations () at 
../../src/gdb/breakpoint.c:10670
#2  0x0000000000673111 in update_global_location_list (should_insert=1) 
at ../../src/gdb/breakpoint.c:11021
#3  0x0000000000663752 in create_overlay_event_breakpoint () at 
../../src/gdb/breakpoint.c:2322
#4  0x0000000000675c9f in breakpoint_re_set () at 
../../src/gdb/breakpoint.c:12621
#5  0x00000000007efe65 in solib_add (pattern=0x0, from_tty=1, 
target=0x1d1e860, readsyms=1)
      at ../../src/gdb/solib.c:928
#6  0x000000000057b452 in enable_break (info=0x3307890, from_tty=1) at 
../../src/gdb/solib-svr4.c:1624
#7  0x000000000057c428 in svr4_solib_create_inferior_hook (from_tty=1) 
at ../../src/gdb/solib-svr4.c:2234
#8  0x00000000007f04a9 in solib_create_inferior_hook (from_tty=1) at 
../../src/gdb/solib.c:1172
#9  0x00000000006cc8e5 in post_create_inferior (target=0x1d1e860, 
from_tty=1) at ../../src/gdb/infcmd.c:431
#10 0x00000000006d479d in start_remote (from_tty=1) at 
../../src/gdb/infrun.c:2309
#11 0x00000000005d80c9 in remote_start_remote (from_tty=1, 
target=0x1cefce0, extended_p=0)
      at ../../src/gdb/remote.c:3367

The idea of this patch is let remote_get_trace_status doesn't try to 
access to target status before remote_start_remote call 
remote_get_trace_status.  Then when GDB call 
download_tracepoint_locations try to download tracepoint before call 
remote_get_trace_status, it will got !ts->running_known in 
remote_can_download_tracepoint.  Then GDB will not download tracepoint 
before remote_start_remote call remote_get_trace_status.

BTW, to handle this issue we need patch in
http://sourceware.org/ml/gdb-patches/2012-01/msg01008.html too.

Thanks,
Hui

2012-02-27  Hui Zhu  <hui_zhu@mentor.com>
	    Yao Qi  <yao@codesourcery.com>

	* remote.c (remote_start_remote): ts->initialized to false in the
	begin of this function and set it to true before
	call remote_get_trace_status.
	(remote_get_trace_status): Return directly if ts->initialized is false.
	tracepoint.c(tfile_open): Set ts->initialized to true.
	tracepoint.h(trace_status): Add initialized.



[-- Attachment #2: reset-trace-status.txt --]
[-- Type: text/plain, Size: 2956 bytes --]

---
 remote.c     |   30 ++++++++++++++++++++----------
 tracepoint.c |    1 +
 tracepoint.h |    3 +++
 3 files changed, 24 insertions(+), 10 deletions(-)

--- a/remote.c
+++ b/remote.c
@@ -3203,6 +3203,7 @@ remote_start_remote (int from_tty, struc
   struct remote_state *rs = get_remote_state ();
   struct packet_config *noack_config;
   char *wait_status = NULL;
+  struct trace_status *ts = current_trace_status ();
 
   immediate_quit++;		/* Allow user to interrupt it.  */
 
@@ -3212,6 +3213,9 @@ remote_start_remote (int from_tty, struc
   /* Ack any packet which the remote side has already sent.  */
   serial_write (remote_desc, "+", 1);
 
+  /* Set status to not initialized.  */
+  ts->initialized = 0;
+
   /* The first packet we send to the target is the optional "supported
      packets" request.  If the target can answer this, it will tell us
      which later probes to skip.  */
@@ -3435,7 +3439,8 @@ remote_start_remote (int from_tty, struc
 
   /* Possibly the target has been engaged in a trace run started
      previously; find out where things are at.  */
-  if (remote_get_trace_status (current_trace_status ()) != -1)
+  ts->initialized = 1;
+  if (remote_get_trace_status (ts) != -1)
     {
       struct uploaded_tp *uploaded_tps = NULL;
       struct uploaded_tsv *uploaded_tsvs = NULL;
@@ -10276,6 +10281,19 @@ remote_get_trace_status (struct trace_st
   extern int trace_regblock_size;
   volatile struct gdb_exception ex;
 
+  /* We're working with a live target.  */
+  ts->from_file = 0;
+
+  /* Set some defaults.  */
+  ts->running_known = 0;
+  ts->stop_reason = trace_stop_reason_unknown;
+  ts->traceframe_count = -1;
+  ts->buffer_free = 0;
+  ts->running = 0;
+
+  if (!ts->initialized)
+    goto out;
+
   trace_regblock_size = get_remote_arch_state ()->sizeof_g_packet;
 
   putpkt ("qTStatus");
@@ -10294,20 +10312,12 @@ remote_get_trace_status (struct trace_st
   if (*p == '\0')
     return -1;
 
-  /* We're working with a live target.  */
-  ts->from_file = 0;
-
-  /* Set some defaults.  */
-  ts->running_known = 0;
-  ts->stop_reason = trace_stop_reason_unknown;
-  ts->traceframe_count = -1;
-  ts->buffer_free = 0;
-
   if (*p++ != 'T')
     error (_("Bogus trace status reply from target: %s"), target_buf);
 
   parse_trace_status (p, ts);
 
+out:
   return ts->running;
 }
 
--- a/tracepoint.c
+++ b/tracepoint.c
@@ -3670,6 +3670,7 @@ tfile_open (char *filename, int from_tty
 
   trace_regblock_size = 0;
   ts = current_trace_status ();
+  ts->initialized = 1;
   /* We know we're working with a file.  */
   ts->from_file = 1;
   /* Set defaults in case there is no status line.  */
--- a/tracepoint.h
+++ b/tracepoint.h
@@ -72,6 +72,9 @@ enum trace_stop_reason
 
 struct trace_status
 {
+  /* The target will try to get the status only when this is true.  */
+  int initialized;
+
   /* This is true if the status is coming from a file rather
      than a live target.  */
   int from_file;

Re: Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status

[Pedro Alves]

Hi Hui, Yao.  Sorry for the delay.  I'm looking at this now.

On 03/01/2012 02:46 PM, Hui Zhu wrote:
> Hi Pedro,
> 
> After discussion with Yao in irc, our thought is if we want handle it in update_global_location_list, there will a lot of part need to be change, because there are a lot of call level.  For example:
> #0  remote_download_tracepoint (loc=0x35040b0) at ../../src/gdb/remote.c:9982
> #1  0x00000000006727c1 in download_tracepoint_locations () at ../../src/gdb/breakpoint.c:10670
> #2  0x0000000000673111 in update_global_location_list (should_insert=1) at ../../src/gdb/breakpoint.c:11021
> #3  0x0000000000663752 in create_overlay_event_breakpoint () at ../../src/gdb/breakpoint.c:2322
> #4  0x0000000000675c9f in breakpoint_re_set () at ../../src/gdb/breakpoint.c:12621
> #5  0x00000000007efe65 in solib_add (pattern=0x0, from_tty=1, target=0x1d1e860, readsyms=1)
>      at ../../src/gdb/solib.c:928
> #6  0x000000000057b452 in enable_break (info=0x3307890, from_tty=1) at ../../src/gdb/solib-svr4.c:1624
> #7  0x000000000057c428 in svr4_solib_create_inferior_hook (from_tty=1) at ../../src/gdb/solib-svr4.c:2234
> #8  0x00000000007f04a9 in solib_create_inferior_hook (from_tty=1) at ../../src/gdb/solib.c:1172
> #9  0x00000000006cc8e5 in post_create_inferior (target=0x1d1e860, from_tty=1) at ../../src/gdb/infcmd.c:431
> #10 0x00000000006d479d in start_remote (from_tty=1) at ../../src/gdb/infrun.c:2309
> #11 0x00000000005d80c9 in remote_start_remote (from_tty=1, target=0x1cefce0, extended_p=0)
>      at ../../src/gdb/remote.c:3367
> 
> The idea of this patch is let remote_get_trace_status doesn't try to access to target status before remote_start_remote call remote_get_trace_status.  Then when GDB call download_tracepoint_locations try to download tracepoint before call remote_get_trace_status, it will got !ts->running_known in remote_can_download_tracepoint.  Then GDB will not download tracepoint before remote_start_remote call remote_get_trace_status.
> 
> BTW, to handle this issue we need patch in
> http://sourceware.org/ml/gdb-patches/2012-01/msg01008.html too.
> 

I think this is close, but still not quite right.  This isn't fundamentally
about the remote side's trace status; so having remote_get_trace_status
return something different while going through initialization feels wrong.
Let me try tweaking this a bit.  I'll also hack a bit on patch 2/2.

> Thanks,
> Hui
> 
> 2012-02-27  Hui Zhu  <hui_zhu@mentor.com>
>         Yao Qi  <yao@codesourcery.com>
> 
>     * remote.c (remote_start_remote): ts->initialized to false in the
>     begin of this function and set it to true before
>     call remote_get_trace_status.
>     (remote_get_trace_status): Return directly if ts->initialized is false.
>     tracepoint.c(tfile_open): Set ts->initialized to true.
>     tracepoint.h(trace_status): Add initialized.


-- 
Pedro Alves

Re: Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status

[Pedro Alves]

On 03/01/2012 05:33 PM, Pedro Alves wrote:

> I think this is close, but still not quite right.  This isn't fundamentally
> about the remote side's trace status; so having remote_get_trace_status
> return something different while going through initialization feels wrong.
> Let me try tweaking this a bit.  I'll also hack a bit on patch 2/2.

On 02/08/2012 06:31 PM, Pedro Alves wrote:

> It may be simpler and safer to just have a way for update_global_location_list
> to know that it shouldn't try to install tracepoints yet (cause we're still going
> through startup)?

This is closer to what I was thinking.

Would you like to write a test case for this (please :-)) ?

WDYT?

2012-03-01  Pedro Alves  <palves@redhat.com>
	    Hui Zhu  <hui_zhu@mentor.com>
	    Yao Qi  <yao@codesourcery.com>

	* remote.c (struct remote_state): New field `starting_up'.
	(remote_start_remote): Set and clear it.
	(remote_can_download_tracepoint): If starting up, return false.

---

 gdb/remote.c |   28 ++++++++++++++++++++++++++--
 1 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/gdb/remote.c b/gdb/remote.c
index 2719241..611921d 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -273,6 +273,10 @@ struct remote_state
   char *buf;
   long buf_size;

+  /* True if we're going through initial connection setup (finding out
+     about the remote side's threads, relocating symbols, etc.).  */
+  int starting_up;
+
   /* If we negotiated packet size explicitly (and thus can bypass
      heuristics for the largest packet size that will not overflow
      a buffer in the stub), this will be set to that packet size.
@@ -3219,6 +3223,10 @@ remote_start_remote (int from_tty, struct target_ops *target, int extended_p)
   /* Ack any packet which the remote side has already sent.  */
   serial_write (remote_desc, "+", 1);

+  /* Signal other parts that we're going through the initial setup,
+     and so things may not be stable yet.  */
+  rs->starting_up = 1;
+
   /* The first packet we send to the target is the optional "supported
      packets" request.  If the target can answer this, it will tell us
      which later probes to skip.  */
@@ -3462,6 +3470,12 @@ remote_start_remote (int from_tty, struct target_ops *target, int extended_p)
       merge_uploaded_tracepoints (&uploaded_tps);
     }

+  /* The thread and inferior lists are now synchronized with the
+     target, our symbols have been relocated, and we're merged the
+     target's tracepoints with ours.  We're done with basic start
+     up.  */
+  rs->starting_up = 0;
+
   /* If breakpoints are global, insert them now.  */
   if (gdbarch_has_global_breakpoints (target_gdbarch)
       && breakpoints_always_inserted_mode ())
@@ -10221,8 +10235,18 @@ remote_download_tracepoint (struct bp_location *loc)
 static int
 remote_can_download_tracepoint (void)
 {
-  struct trace_status *ts = current_trace_status ();
-  int status = remote_get_trace_status (ts);
+  struct remote_state *rs = get_remote_state ();
+  struct trace_status *ts;
+  int status;
+
+  /* Don't try to install tracepoints until we've relocated our
+     symbols, and fetched and merged the target's tracepoint list with
+     ours.  */
+  if (rs->starting_up)
+    return 0;
+
+  ts = current_trace_status ();
+  status = remote_get_trace_status (ts);

   if (status == -1 || !ts->running_known || !ts->running)
     return 0;

Re: Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status

[Hui Zhu]

On Fri, Mar 2, 2012 at 02:49, Pedro Alves <palves@redhat.com> wrote:
> On 03/01/2012 05:33 PM, Pedro Alves wrote:
>
>> I think this is close, but still not quite right.  This isn't fundamentally
>> about the remote side's trace status; so having remote_get_trace_status
>> return something different while going through initialization feels wrong.
>> Let me try tweaking this a bit.  I'll also hack a bit on patch 2/2.
>
> On 02/08/2012 06:31 PM, Pedro Alves wrote:
>
>> It may be simpler and safer to just have a way for update_global_location_list
>> to know that it shouldn't try to install tracepoints yet (cause we're still going
>> through startup)?
>
> This is closer to what I was thinking.
>
> Would you like to write a test case for this (please :-)) ?
>
> WDYT?

I think this patch is better.  Thanks.

I will write the testsuite.

I still have some copyright issue with hui_zhu@mentor.com email
address, please use teawater@gmail.com if you commit this patch.
Sorry for it.

Best,
Hui

>
> 2012-03-01  Pedro Alves  <palves@redhat.com>
>            Hui Zhu  <hui_zhu@mentor.com>
>            Yao Qi  <yao@codesourcery.com>
>
>        * remote.c (struct remote_state): New field `starting_up'.
>        (remote_start_remote): Set and clear it.
>        (remote_can_download_tracepoint): If starting up, return false.
>
> ---
>
>  gdb/remote.c |   28 ++++++++++++++++++++++++++--
>  1 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/remote.c b/gdb/remote.c
> index 2719241..611921d 100644
> --- a/gdb/remote.c
> +++ b/gdb/remote.c
> @@ -273,6 +273,10 @@ struct remote_state
>   char *buf;
>   long buf_size;
>
> +  /* True if we're going through initial connection setup (finding out
> +     about the remote side's threads, relocating symbols, etc.).  */
> +  int starting_up;
> +
>   /* If we negotiated packet size explicitly (and thus can bypass
>      heuristics for the largest packet size that will not overflow
>      a buffer in the stub), this will be set to that packet size.
> @@ -3219,6 +3223,10 @@ remote_start_remote (int from_tty, struct target_ops *target, int extended_p)
>   /* Ack any packet which the remote side has already sent.  */
>   serial_write (remote_desc, "+", 1);
>
> +  /* Signal other parts that we're going through the initial setup,
> +     and so things may not be stable yet.  */
> +  rs->starting_up = 1;
> +
>   /* The first packet we send to the target is the optional "supported
>      packets" request.  If the target can answer this, it will tell us
>      which later probes to skip.  */
> @@ -3462,6 +3470,12 @@ remote_start_remote (int from_tty, struct target_ops *target, int extended_p)
>       merge_uploaded_tracepoints (&uploaded_tps);
>     }
>
> +  /* The thread and inferior lists are now synchronized with the
> +     target, our symbols have been relocated, and we're merged the
> +     target's tracepoints with ours.  We're done with basic start
> +     up.  */
> +  rs->starting_up = 0;
> +
>   /* If breakpoints are global, insert them now.  */
>   if (gdbarch_has_global_breakpoints (target_gdbarch)
>       && breakpoints_always_inserted_mode ())
> @@ -10221,8 +10235,18 @@ remote_download_tracepoint (struct bp_location *loc)
>  static int
>  remote_can_download_tracepoint (void)
>  {
> -  struct trace_status *ts = current_trace_status ();
> -  int status = remote_get_trace_status (ts);
> +  struct remote_state *rs = get_remote_state ();
> +  struct trace_status *ts;
> +  int status;
> +
> +  /* Don't try to install tracepoints until we've relocated our
> +     symbols, and fetched and merged the target's tracepoint list with
> +     ours.  */
> +  if (rs->starting_up)
> +    return 0;
> +
> +  ts = current_trace_status ();
> +  status = remote_get_trace_status (ts);
>
>   if (status == -1 || !ts->running_known || !ts->running)
>     return 0;

Re: Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status

[Hui Zhu]

Hi Pedro,

I had made sure that the FSF acknowledged my copyright assignment mid
february.  So this email is OK now.

And I found that this issue affect 7.4 too.  I suggest commit this
patch to 7.4 branch too.

Thanks,
Hui

On Mon, Mar 5, 2012 at 10:25, Hui Zhu <teawater@gmail.com> wrote:
> On Fri, Mar 2, 2012 at 02:49, Pedro Alves <palves@redhat.com> wrote:
>> On 03/01/2012 05:33 PM, Pedro Alves wrote:
>>
>>> I think this is close, but still not quite right.  This isn't fundamentally
>>> about the remote side's trace status; so having remote_get_trace_status
>>> return something different while going through initialization feels wrong.
>>> Let me try tweaking this a bit.  I'll also hack a bit on patch 2/2.
>>
>> On 02/08/2012 06:31 PM, Pedro Alves wrote:
>>
>>> It may be simpler and safer to just have a way for update_global_location_list
>>> to know that it shouldn't try to install tracepoints yet (cause we're still going
>>> through startup)?
>>
>> This is closer to what I was thinking.
>>
>> Would you like to write a test case for this (please :-)) ?
>>
>> WDYT?
>
> I think this patch is better.  Thanks.
>
> I will write the testsuite.
>
> I still have some copyright issue with hui_zhu@mentor.com email
> address, please use teawater@gmail.com if you commit this patch.
> Sorry for it.
>
> Best,
> Hui
>
>>
>> 2012-03-01  Pedro Alves  <palves@redhat.com>
>>            Hui Zhu  <hui_zhu@mentor.com>
>>            Yao Qi  <yao@codesourcery.com>
>>
>>        * remote.c (struct remote_state): New field `starting_up'.
>>        (remote_start_remote): Set and clear it.
>>        (remote_can_download_tracepoint): If starting up, return false.
>>
>> ---
>>
>>  gdb/remote.c |   28 ++++++++++++++++++++++++++--
>>  1 files changed, 26 insertions(+), 2 deletions(-)
>>
>> diff --git a/gdb/remote.c b/gdb/remote.c
>> index 2719241..611921d 100644
>> --- a/gdb/remote.c
>> +++ b/gdb/remote.c
>> @@ -273,6 +273,10 @@ struct remote_state
>>   char *buf;
>>   long buf_size;
>>
>> +  /* True if we're going through initial connection setup (finding out
>> +     about the remote side's threads, relocating symbols, etc.).  */
>> +  int starting_up;
>> +
>>   /* If we negotiated packet size explicitly (and thus can bypass
>>      heuristics for the largest packet size that will not overflow
>>      a buffer in the stub), this will be set to that packet size.
>> @@ -3219,6 +3223,10 @@ remote_start_remote (int from_tty, struct target_ops *target, int extended_p)
>>   /* Ack any packet which the remote side has already sent.  */
>>   serial_write (remote_desc, "+", 1);
>>
>> +  /* Signal other parts that we're going through the initial setup,
>> +     and so things may not be stable yet.  */
>> +  rs->starting_up = 1;
>> +
>>   /* The first packet we send to the target is the optional "supported
>>      packets" request.  If the target can answer this, it will tell us
>>      which later probes to skip.  */
>> @@ -3462,6 +3470,12 @@ remote_start_remote (int from_tty, struct target_ops *target, int extended_p)
>>       merge_uploaded_tracepoints (&uploaded_tps);
>>     }
>>
>> +  /* The thread and inferior lists are now synchronized with the
>> +     target, our symbols have been relocated, and we're merged the
>> +     target's tracepoints with ours.  We're done with basic start
>> +     up.  */
>> +  rs->starting_up = 0;
>> +
>>   /* If breakpoints are global, insert them now.  */
>>   if (gdbarch_has_global_breakpoints (target_gdbarch)
>>       && breakpoints_always_inserted_mode ())
>> @@ -10221,8 +10235,18 @@ remote_download_tracepoint (struct bp_location *loc)
>>  static int
>>  remote_can_download_tracepoint (void)
>>  {
>> -  struct trace_status *ts = current_trace_status ();
>> -  int status = remote_get_trace_status (ts);
>> +  struct remote_state *rs = get_remote_state ();
>> +  struct trace_status *ts;
>> +  int status;
>> +
>> +  /* Don't try to install tracepoints until we've relocated our
>> +     symbols, and fetched and merged the target's tracepoint list with
>> +     ours.  */
>> +  if (rs->starting_up)
>> +    return 0;
>> +
>> +  ts = current_trace_status ();
>> +  status = remote_get_trace_status (ts);
>>
>>   if (status == -1 || !ts->running_known || !ts->running)
>>     return 0;

Re: Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status

[Pedro Alves]

On 03/11/2012 04:12 PM, Hui Zhu wrote:

> Hi Pedro,
> 
> I had made sure that the FSF acknowledged my copyright assignment mid
> february.  So this email is OK now.


I consulted with the FSF copyright clerk, and I was told your paperwork
isn't fully sort out yet, so you can't yet transfer changes on behalf of
Mentor.   You can however contribute your own independent changes
meanwhile (under your personal assignment), as there's trust that Mentor
is good about getting their paperwork in regularly.  In this particular case,
I've gone ahead and checked in the patches.  But again, please let's make
sure the paperwork is fully done before you can transfer changes on
behalf of Mentor.

> And I found that this issue affect 7.4 too.  I suggest commit this
> patch to 7.4 branch too.


It'd be good to have a testcase.  ;-)  I'm not sure if 7.4 has all the
bits necessary?  I'll check it out.

-- 
Pedro Alves

Re: Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status

[Pedro Alves]

On 03/13/2012 01:46 PM, Pedro Alves wrote:

>> And I found that this issue affect 7.4 too.  I suggest commit this
>> patch to 7.4 branch too.
> 
> 
> It'd be good to have a testcase.  ;-)  I'm not sure if 7.4 has all the
> bits necessary?  I'll check it out.


I've confirmed that just these patches were needed to fix this.  I've
checked them in in the 7.4 branch now.

-- 
Pedro Alves

Fix tracepoints in extended-remote mode regression (Re: Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status)

[Pedro Alves]

On 03/01/2012 06:49 PM, Pedro Alves wrote:

> 
> 2012-03-01  Pedro Alves  <palves@redhat.com>
> 	    Hui Zhu  <hui_zhu@mentor.com>
> 	    Yao Qi  <yao@codesourcery.com>
> 
> 	* remote.c (struct remote_state): New field `starting_up'.
> 	(remote_start_remote): Set and clear it.
> 	(remote_can_download_tracepoint): If starting up, return false.


This misses clearing `starting_up' on early return paths of remote_start_remote,
an so remote_can_download_tracepoint always return false in extended-remote mode.
With the extended-remote board, but not with the regular remote board:

Running ../../../src/gdb/testsuite/gdb.trace/change-loc.exp ...
FAIL: gdb.trace/change-loc.exp: 1 trace: tfind frame 0
FAIL: gdb.trace/change-loc.exp: 2 trace: tfind frame 2
FAIL: gdb.trace/change-loc.exp: 1 ftrace: running to main in runto
FAIL: gdb.trace/change-loc.exp: 1 ftrace: Can't run to main
FAIL: gdb.trace/change-loc.exp: 2 ftrace: run to main (the program exited)
FAIL: gdb.trace/change-loc.exp: 2 ftrace: tstart
...
(snip yet more fails)

This fixes it.  Applied on mainline and 7.4.

2012-03-20  Pedro Alves  <palves@redhat.com>

	* remote.c (remote_start_remote): Clear `rs->starting_up' on early
	returns.
---
 gdb/remote.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Index: src/gdb/remote.c
===================================================================
--- src.orig/gdb/remote.c
+++ src/gdb/remote.c
@@ -3268,6 +3268,7 @@ remote_start_remote (int from_tty, struc

 	  /* We're connected, but not running.  Drop out before we
 	     call start_remote.  */
+	  rs->starting_up = 0;
 	  return;
 	}
       else
@@ -3374,6 +3375,7 @@ remote_start_remote (int from_tty, struc

 	  /* We're connected, but not running.  Drop out before we
 	     call start_remote.  */
+	  rs->starting_up = 0;
 	  return;
 	}