Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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 14:41:00 -0000	[thread overview]
Message-ID: <201111171441.15620.pedro@codesourcery.com> (raw)
In-Reply-To: <4EC51A8D.8080007@codesourcery.com>

On Thursday 17 November 2011 14:30:37, Yao Qi wrote:
> On 11/17/2011 08:28 PM, Pedro Alves wrote:
> >> > +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:
> > 
> 
> I agree that "pending tracepoints still exist" is confusing, and we
> should remove this sentence.  However, I don't think we should express
> "pending tracepoints don't work with disconnected tracing.", because,
> "pending tracepoints" and "disconnected tracing" are orthogonal to each
> other.  A remote stub can support either/both/none of them.

But if the target doesn't support disconnected tracing, tracing always
stops on disconnection, and so mentioning that pending tracepoints don't
resolve isn't interesting for that case.  The ability to resolve or not
pending tracepoints while gdb is disconnected is only interesting from the
target's perpective _while_ a trace run is ongoing.  From gdb's
perspective, once the remote target goes away, there's nothing special about
pending tracepoints compared to other types of breakpoints.

> > 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
> 
> ...so I suggest remove "(@pxref{disconnected tracing})" here.  What do
> you think?

I do think we should have that reference there.

-- 
Pedro Alves


  reply	other threads:[~2011-11-17 14:41 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
2011-11-17 14:31             ` Yao Qi
2011-11-17 14:41               ` Pedro Alves [this message]
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=201111171441.15620.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