From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22677 invoked by alias); 22 Feb 2015 16:38:53 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 22599 invoked by uid 89); 22 Feb 2015 16:38:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_FROM_URIBL_PCCC,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-qc0-f170.google.com Received: from mail-qc0-f170.google.com (HELO mail-qc0-f170.google.com) (209.85.216.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sun, 22 Feb 2015 16:38:51 +0000 Received: by qcvp6 with SMTP id p6so7857167qcv.12 for ; Sun, 22 Feb 2015 08:38:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.229.78.137 with SMTP id l9mr4521210qck.11.1424623128838; Sun, 22 Feb 2015 08:38:48 -0800 (PST) Received: by 10.229.40.69 with HTTP; Sun, 22 Feb 2015 08:38:48 -0800 (PST) In-Reply-To: <17376.1423856828@usendtaylorx2l> References: <4250.1411074396@usendtaylorx2l> <13378.1413479010@usendtaylorx2l> <5440356E.3080705@redhat.com> <54405367.9030000@earthlink.net> <17376.1423856828@usendtaylorx2l> Date: Sun, 22 Feb 2015 16:38:00 -0000 Message-ID: Subject: Re: filtering traceframes (was: Re: possible QTFrame enhancement) From: Doug Evans To: David Taylor Cc: Stan Shebs , "gdb@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00039.txt.bz2 On Fri, Feb 13, 2015 at 11:47 AM, David Taylor 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 > > 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 > [-r | --reverse] > [-e | --expr ] > > > where [-e | --expr ] would only be defined for those tfind > subcommands where it made sense. > > Using the existing QTFrame remote protocol messages but tacking on > > :X, > > 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 -e then "tfind pc " == "tfind -p " 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 expr tfind expr 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 " and "range|outside ," in an expression, and thus have something like: tfind expr ($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.