This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status
- From: Pedro Alves <palves at redhat dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Hui Zhu <hui_zhu at mentor dot com>, gdb-patches at sourceware dot org, Yao Qi <Yao_Qi at mentor dot com>
- Date: Thu, 01 Mar 2012 18:49:17 +0000
- Subject: Re: Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status
- References: <4F4F8BE2.7030503@mentor.com> <4F4FB2F9.80200@redhat.com>
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;