Re: PATCH: Circular trace buffers

[Stan Shebs <stan@codesourcery.com>]

Pedro Alves wrote:
>> 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.
...and you may recall, we've been requested to add the ability to 
disable tracepoints during a run.
> 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.  :-)
>   
If I had to guess, I'd say that the ultimate long-term model will tend 
toward on-the-fly change, rather than having it be a one-shot thing.  It 
is potentially messy to implement (tracepoint definitions that only 
apply to a subset of trace frames? ugh), but is more consistent with 
GDB's overall philosophy of letting users do whatever they can think of.
>   
>>>  - 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.
>   
Hmm, that doesn't sound good, guess I should investigate further.
>   
>>>  - 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.
>   
I'm just not seeing a problem myself - it seems obvious that circularity 
of trace buffer only matters for future tracepoint hits, and doesn't 
matter for completed trace runs, trace files, etc.  But I can rephrase 
the docs to make that clearer.

Stan