This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
filtering traceframes (was: Re: possible QTFrame enhancement)
- From: David Taylor <dtaylor at emc dot com>
- To: Stan Shebs <stanshebs at earthlink dot net>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Fri, 13 Feb 2015 14:47:08 -0500
- Subject: filtering traceframes (was: Re: possible QTFrame enhancement)
- Authentication-results: sourceware.org; auth=none
- References: <4250 dot 1411074396 at usendtaylorx2l> <13378 dot 1413479010 at usendtaylorx2l> <5440356E dot 3080705 at redhat dot com> <54405367 dot 9030000 at earthlink dot net>
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