Re: possible QTFrame enhancement

[Stan Shebs <stanshebs@earthlink.net>]

On 10/16/14, 2:15 PM, Pedro Alves wrote:
> On 10/16/2014 06:03 PM, David Taylor wrote:
>> In mid September I asked about a possible QTFrame / tfind enhancement.
>> That message generated zero responses.
>>
>> I'm hoping to get back in a day or two to our effort of adding the
>> setting of memory and registers at tracepoints.  (It's more than half
>> done; but, before I finished I got yanked onto another project.)  I
>> won't be working on implementing these proposed QTFrame / tframe
>> enhancements until that (and possibly some other stuff) is done.
>>
>> For the remote protocol there currently several variants of the QTFrame
>> message:
>>
>>     QTFrame:n
>>     QTFrame:pc:addr
>>     QTFrame:tdp:t
>>     QTFrame:range:start:end
>>     QTFrame:outside:start:end
>>
>> And variants of the tfind command:
>>
>>     tfind end
>>     tfind line
>>     tfind none
>>     tfind outside
>>     tfind pc
>>     tfind range
>>     tfind start
>>     tfind tracepoint
>>
>> We (EMC) have a developer who runs trace experiments that generate
>> *LOTS* of tracepoint frames -- possibly 100,000 or more!  He then likes
>> to find an anomaly and search *BACKWARDS* to find where things first
>> started going bad.
> 
> That makes a lot of sense.  Kind of a glaring omission, even.
> 
> In a way, "tfind" is like "si/step/etc", and "tfind -r" would
> be like "reverse-si/step/etc".
> 
>>
>> Other than the first QTFrame variant above -- which does no searching --
>> all of the above QTFrame variants search *FORWARDS* from the current
>> tracepoint frame.
>>
>> I would like to propose that tfind be modified from
>>
>>     tfind <existing-subcommand> <existing-arguments>
>> to
>>
>>     tfind <existing-subcommand> [ -r | --reverse] <existing-arguments>
>>
>> and that the QTFrame remote protocol message have an optional `-' before
>> the first `:' to indicate reverse:
>>
>>     QTFrame-:n
> 
> This one doesn't seem to make sense.  QTFrame:n means "find frame number N".
> How would that be any different?

"N from the last frame" perhaps?  Although GDB does get told how many
trace frames have been collected, so it can calculate "N from the end"
itself.

>> Does this proposal seem reasonable to people?  Would an implementation
>> of this stand a resonable chance of being accepted back?
> 
> Yes.  If it comes along with a reference implementation in
> gdbserver, even better.

I concur.  I can't think of many other actual tracepoint users right
now, so your developer gets lots of influence on how it develops
further.

One funky idea that occurs to me, looking at this proposal - QTFrame
packet with an agent expression?  The whole theory of QTFrame is to
instruct the target how to find a trace frame, so if you have lots of
trace frames, maybe you'd want to find by content:

	tfind collectedvar < 0

Compile expression to bytecode, pass it in packet, let the target agent
iterate over the trace buffer and report first one found.  It would be
some weird byecode interpreter hackery I suppose, reading from buffer
instead of live memory, but probably OK speedwise, since everything is
in RAM.

Stan
stan@codesourcery.com