Re: PATCH: Circular trace buffers

[Stan Shebs <stan@codesourcery.com>]

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.
> 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.
>  - 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?
>  - 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?

Stan