Re: possible QTFrame enhancement

[David Taylor <dtaylor at usendtaylorx2l dot lss dot emc dot com>]

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.

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
    QTFrame-:pc:addr
    QTFrame-:tdp:t
    QTFrame-:range: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?

Thanks.

David