PATCH: Circular trace buffers
Stan Shebs
stan@codesourcery.com
Wed Mar 17 18:05:00 GMT 2010
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
More information about the Gdb-patches
mailing list