Re: possible QTFrame enhancement

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?

>     QTFrame-:pc:addr
>     QTFrame-:tdp:t
>     QTFrame-:range:start:end
>     QTFrame-:outside:start:end

I think it might make sense to put the '-' on the "how" part
then, that is, after the ':', thus we'd have:

     QTFrame:n
     QTFrame:pc:addr
     QTFrame:-pc:addr
     QTFrame:tdp:t
     QTFrame:-tdp:t
     QTFrame:range:start:end
     QTFrame:-range:start:end
     QTFrame:outside:start:end
     QTFrame:-outside:start:end

> 
> And for qSupported I propose:
> 
>     QTFrameReverse+
>     QTFrameReverse-
> 
> to indicate whether it is supported or not.
> 
> 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.

Thanks,
Pedro Alves