This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

filtering traceframes (was: Re: possible QTFrame enhancement)


I've been thinking some more about filtering traceframes.

You can think of the variations of tfind command as basically being
filtering variants.  Show me the next / previous trace frame

. at a particular pc (tfind pc)
. from a particular tracepoint (tfind tp)
. within some pc range (tfind range)
. outside some pc range (tfind outside)

And we have users that do filtering, on the desktop, based on other
criteria.

I would like to move much of this filtering to the stub.

If you have a small number of trace frames or if most of your trace
frame 'match' the filter, then it probably doesn't matter where the
filtering is done.  But, if you have a large number of frame (e.g., over
100,000) and a small fraction (say, 1/1000) match the filter, then
it can make a big difference to where the filtering occurs.

At first I was thinking just support

    tfind expr <expression>

but on reflection, I don't think that that is enough.  You want to be
able to say ``give me the next / previous trace frame that is

. at a particular pc (tfind pc)
. from a particular tracepoint (tfind tp)
. within some pc range (tfind range)
. outside some pc range (tfind outside)

*AND* matches this expression.

So, now I'm thinking, for user interface:

tfind <tfind subcommand>
    [-r | --reverse]
    [-e <expr> | --expr <expr>]
    <subcommand args>

where [-e <expr> | --expr <expr>] would only be defined for those tfind
subcommands where it made sense.

Using the existing QTFrame remote protocol messages but tacking on

    :X<byte count>,<hex encoded expression>

at the end.  And letting GDB know that the stub supports it by adding
TraceFrameExprs followed by '+' or '-' to the qSupported response.
(Default being either not supported or probe for it (assuming there's a
reasonable way to probe for it.))

I haven't begun to think about implementation details (and I have other
things on my plate, so I'm certain to not get to it this quarter even if
I get management approval), but I would like feedback and thoughts.

David
dtaylor at emc dot com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]