possible QTFrame enhancement

[David Taylor <dtaylor@emc.com>]

For the remote protocol QTFrame message there are everal variants:

    QTFrame:n

        select the n'th tracepoint frame from the buffer

    QTFrame:pc:addr

        select the first tracepoint frame *AFTER* the currently seelctd
        frame whose PC is addr.

    QTFrame:tdp:t

        select the first tracepoint frame *AFTER* the currently selected
        tracepoint frame that is a hit of tracepoint t.

    QTFrame:range:start:end

        select the first tracepoint frame *AFTER* the currently selected
        fraome whose PC is between start and end

    QTFrame:outside:start:end

        select the first tracepoint frame *AFTER* the currently selected
        frame whose PC is outside the range of addresses.

Which are used by the tfind command and its subcommands:

    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.

If there was support for searching backwards, what form should it take?

. what should the QTFrame message(s) be?

. what should the tfind commands be?

. should there be a 'token' returned by qSupported to indicate support
for the new messages?  And if so, what 'token'?  Or should GDB figure it
out by sending one of the messages and trusting that it will get an
error if it is unsupported?

David