Re: filtering traceframes (was: Re: possible QTFrame enhancement)

On Fri, Feb 13, 2015 at 11:47 AM, David Taylor <[email protected]> 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.