From: Pedro Alves <pedro@codesourcery.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org, Eli Zaretskii <eliz@gnu.org>,
Luis Machado <luis_gustavo@mentor.com>
Subject: Re: [patch 5/5] Document
Date: Thu, 17 Nov 2011 12:28:00 -0000 [thread overview]
Message-ID: <201111171228.16603.pedro@codesourcery.com> (raw)
In-Reply-To: <4EC47E7F.2090202@codesourcery.com>
On Thursday 17 November 2011 03:24:47, Yao Qi wrote:
> +until they are resolved. The resolution of pending tracepoints requires
> +@value{GDBN} support--in the remote target, when @value{GDBN}
I think it really needs to be three dashes.
> +disconnects from the remote stub, pending tracepoints still exist but
> +can not be resolved while @value{GDBN} is disconnected.
Sorry to be picky, but I'm trying to read this from a user's perspective,
and it still confuses me. What does "pending tracepoints still exist"
mean? Do you mean they still exist in GDB? That's true for all kinds
of breakpoints, so it doesn't add anything. If you mean that they exist
on the target, then what does it mean for a pending tracepoint to exist
on the target? What we're really trying to say is that pending tracepoints
don't work with disconnected tracing. How about:
The resolution of pending tracepoints requires @value{GDBN} support---
when debugging with the remote target, and @value{GDBN} disconnects from the
remote stub (@pxref{disconnected tracing}), pending tracepoints can not be
resolved (and downloaded to the remote stub) while @value{GDBN} is
disconnected.
?
--
Pedro Alves
next prev parent reply other threads:[~2011-11-17 12:28 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-15 7:01 [patch 0/5] pending tracepoint Yao Qi
2011-11-15 7:30 ` [patch 1/5] Call update_global_location_list conditionally in install_breakpoint Yao Qi
2011-11-16 19:04 ` Pedro Alves
2011-11-15 7:43 ` [patch 2/5] allow pending tracepoint Yao Qi
2011-11-16 19:04 ` Pedro Alves
2011-11-17 1:12 ` Yao Qi
2011-11-15 7:47 ` [patch 3/5] Print a message on gdb disconnected Yao Qi
2011-11-15 15:32 ` Tom Tromey
2011-11-16 3:17 ` Yao Qi
2011-11-16 19:04 ` Pedro Alves
2011-11-17 3:32 ` Yao Qi
2011-11-17 11:08 ` Pedro Alves
2011-11-15 8:03 ` [patch 4/5] Test cases Yao Qi
2011-11-16 19:05 ` Pedro Alves
2011-11-17 3:27 ` Yao Qi
2011-11-17 12:08 ` Pedro Alves
2011-11-17 14:09 ` Yao Qi
2011-11-17 14:54 ` Pedro Alves
2011-11-15 8:08 ` [patch 5/5] Document Yao Qi
2011-11-15 14:29 ` Luis Machado
2011-11-15 14:57 ` Yao Qi
2011-11-15 15:04 ` Luis Machado
2011-11-15 17:02 ` Eli Zaretskii
2011-11-15 17:06 ` Eli Zaretskii
2011-11-16 3:13 ` Yao Qi
2011-11-16 4:01 ` Eli Zaretskii
2011-11-16 19:04 ` Pedro Alves
2011-11-17 3:25 ` Yao Qi
2011-11-17 12:28 ` Pedro Alves [this message]
2011-11-17 14:31 ` Yao Qi
2011-11-17 14:41 ` Pedro Alves
2011-11-17 15:17 ` Yao Qi
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=201111171228.16603.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=luis_gustavo@mentor.com \
--cc=yao@codesourcery.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