Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: Stan Shebs <stan@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: PATCH: Circular trace buffers
Date: Wed, 17 Mar 2010 17:19:00 -0000	[thread overview]
Message-ID: <201003171719.30646.pedro@codesourcery.com> (raw)
In-Reply-To: <4BA1098A.6020800@codesourcery.com>

On Wednesday 17 March 2010 16:55:38, Stan Shebs wrote:
> Pedro Alves wrote:
> > On Tuesday 16 March 2010 21:42:02, Stan Shebs wrote:
> >   
> >> This patch adds a flag that requests the target agent to make the trace 
> >> buffer circular, so that instead of filling it up and then stopping, the 
> >> agent discards the oldest trace frames as necessary to accommodate new 
> >> ones.  Any hairy memory management code is going to be on the target 
> >> side; GDB just has to transmit the setting (and now always via target 
> >> vector), and report back status, which may now include a total number of 
> >> frames that were created.  This also adds complete documentation of the 
> >> qTStatus reply, per request.  Any comments before I commit?
> >>     
> >
> > Playing devil's advogate here, I'm still not 100% convinced that
> > "set circular-trace-buffer" is 100% well defined and that
> > is isn't confusing in some cases; it applies on the fly
> > in some cases, does somewhat not-completly clear
> > things in other cases, and errors out in others.
> Hey Joel, pass me that aspirin bottle, willya? :-)  This is one of those 
> places where I'd like more user feedback before getting too fancy.  It's 
> the opposite situation of expression evaluation - we play fast and loose 
> with language semantics, but we know from extensive experience that 
> users don't want GDB to be too pedantic about visibility, scopes, etc.  
> But for tracepoints we're still mostly guessing.

But I'm not proposing anything fancy, on the contrary, something like:

 (gdb) help set circular-trace-buffer
 Set target's use of circular trace buffer in the next trace run.
 Use this to make the trace buffer into a circular buffer,
 which will discard traceframes (oldest first) instead of filling
 up and stopping the trace run.

Instead of:

 (gdb) help set circular-trace-buffer
 Set target's use of circular trace buffer.
 Use this to make the trace buffer into a circular buffer,
 which will discard traceframes (oldest first) instead of filling
 up and stopping the trace run.

Which doesn't say anything about the setting applying immediately,
or when a new trace run is started.

And:

 (gdb) help show circular-trace-buffer
 Show target's use of circular trace buffer in the next trace run.
 Use this to make the trace buffer into a circular buffer,
 which will discard traceframes (oldest first) instead of filling
 up and stopping the trace run.

Instead of:

 (gdb) help show circular-trace-buffer
 Show target's use of circular trace buffer.
 Use this to make the trace buffer into a circular buffer,
 which will discard traceframes (oldest first) instead of filling
 up and stopping the trace run.


As is "show circular-trace-buffer" is pretty much useless.
Answer this question:  What does this mean, in all supported
cases?

 (gdb) show circular-trace-buffer
 Target's use of circular trace buffer is on.

It looks as though these commands help strings should be
improved to clarify exactly what it means.

> > I wonder
> > if we defined "set circular-trace-buffer" as another flag
> > that is respected at "tstart" time only, and made the
> > presently running trace run's circular-trace-buffer-ness reported
> > through "tstatus", and define "show circular-trace-buffer" as the
> > "circular-trace-buffer-ness" intent at next trace run start,
> > things would be more consistent and clear.

> I thought about that, but it seemed like one of its uses would be as a 
> hasty way to keep a trace run alive; you do a tstatus, say "oh sh*t" as 
> you see the buffer at 80% full before you've reached the code of 
> interest, and quickly switch to circular buffer.

... oh sh*t, I forgot to disable that tracepoint!  Oh darn, you can't
do that when the trace is running.  Same thing, same general problem,
it seems.  This special casing in the circularity-ness adds
inconsistency (everything else is set at tstart time) which I
suspect will byte back.  But it's fine.  I'll just refuse to
address any such inconstencies myself and push the problem
back to you when it happens.  :-)

> >  - all-stop/async + trace running + "set circular-trace-buffer"
> >    errors out because you can't talk to the target if it
> >    is running in all-stop.
> >   

> I think the user would know to interrupt the program, because there's no 
> prompt to type the command at?

Note: "async".  Frontends are switching to use async mode by
default.  "-gdb-set circular-trace-buffer on" does not work
in that case, only in non-stop mode.

> >  - E.g., what does "show circular-trace-buffer" mean when
> >    debugging a tfile?  "set circular-trace-buffer" changes
> >    the local GDB flag, and "show circular-trace-buffer"
> >    shows the according change, but, then we have no
> >    way of knowing when debugging a tfile had been
> >    in circular-trace-buffer mode or not when the tfile
> >    was created.
> >   
> You would know if circularity had kicked in because tstatus on the file 
> would show more frames created than were in the buffer.  If it hadn't 
> kicked in, then the flag's value wouldn't be of much interest, right?

- this shows that "show circular-trace-buffer" is useless.
- this requires users know that fact.
- this doesn't sound user friendly.

-- 
Pedro Alves


  reply	other threads:[~2010-03-17 17:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-16 21:42 Stan Shebs
2010-03-17  7:25 ` Eli Zaretskii
2010-03-17 16:00 ` Pedro Alves
2010-03-17 16:55   ` Stan Shebs
2010-03-17 17:19     ` Pedro Alves [this message]
2010-03-17 18:05       ` Stan Shebs
2010-03-17 18:51         ` Pedro Alves
2010-03-18 22:14           ` Pedro Alves
2010-03-18 23:34             ` Stan Shebs

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=201003171719.30646.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=gdb-patches@sourceware.org \
    --cc=stan@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