This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: filtering traceframes (was: Re: possible QTFrame enhancement)
- From: Doug Evans <xdje42 at gmail dot com>
- To: David Taylor <dtaylor at emc dot com>
- Cc: Stan Shebs <stanshebs at earthlink dot net>, "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Sun, 22 Feb 2015 08:38:48 -0800
- Subject: Re: 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> <17376 dot 1423856828 at usendtaylorx2l>
On Fri, Feb 13, 2015 at 11:47 AM, David Taylor <dtaylor@emc.com> wrote:
> 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
Improving gdb's ability to scale is certainly a goal we want to pursue
so I'm guessing there's no disagreement on wanting something
along these lines.
Another way to go would be to provide a general tfind and make
"tfind pc", etc. special cases of it.
E.g., tfind -p <pc> -e <expr>
then "tfind pc <pc>" == "tfind -p <pc>"
IOW, it's odd to treat expr and pc differently in the syntax.
I'd like to avoid that.
Given how similar "tfind pc ..." and "tfind -p ..." are,
another way to go is:
tfind pc <pc> expr <some_expr>
tfind expr <some_expr> pc <pc>
IOW, for subcommands that specify a condition, allow multiple "subcommands".
Another way to go, though I don't know if this would work as written here,
would be to provide ways of specifying "pc <pc>" and
"range|outside <addr1>,<addr2>" in an expression, and thus have
something like:
tfind expr ($pc == <pc>) && $outside(addr1,addr2) && some_expr
Maybe this would be better:
tfind expr $is_pc(pc) && some_expr
tfind expr $pc_in_range(addr1,addr2) && some_expr
[or whatever spelling for is_pc,pc_in_range, etc. works]
IOW, allow specifying everything in the expression.
One needn't have a replacement for "outside" because it's just:
tfind expr !$pc_in_range(addr1,addr2)
One could even remove "range" and have $is_pc (or whatever)
take one or two arguments.
Anyways, long story short, I don't have a strong preference
other than if we're going to extend things, let's (try to) extend
it in a general direction instead of, e.g., adding -e/--expr to
tfind pc|outside|range.