From: Hui Zhu <hui_zhu@mentor.com>
To: Pedro Alves <palves@redhat.com>, <gdb-patches@sourceware.org>
Cc: Yao Qi <Yao_Qi@mentor.com>
Subject: Fix error when gdb connect to a stub that tracepoint is running[1/2] Add a flag initialized to struct trace_status
Date: Thu, 01 Mar 2012 14:47:00 -0000 [thread overview]
Message-ID: <4F4F8BE2.7030503@mentor.com> (raw)
[-- 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;
next reply other threads:[~2012-03-01 14:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-01 14:47 Hui Zhu [this message]
2012-03-01 18:26 ` Pedro Alves
2012-03-01 18:49 ` Pedro Alves
2012-03-05 2:26 ` Hui Zhu
2012-03-11 16:13 ` Hui Zhu
2012-03-13 13:46 ` Pedro Alves
2012-03-13 22:21 ` Pedro Alves
2012-03-20 18:50 ` 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F4F8BE2.7030503@mentor.com \
--to=hui_zhu@mentor.com \
--cc=Yao_Qi@mentor.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox