From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14387 invoked by alias); 13 Feb 2015 19:50:48 -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 14375 invoked by uid 89); 13 Feb 2015 19:50:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mailuogwhop.emc.com Received: from mailuogwhop.emc.com (HELO mailuogwhop.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 13 Feb 2015 19:50:46 +0000 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id t1DJlOOx010488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Feb 2015 14:47:25 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t1DJlOOx010488 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com t1DJlOOx010488 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by maildlpprd03.lss.emc.com (RSA Interceptor); Fri, 13 Feb 2015 14:47:03 -0500 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id t1DJlA01030018; Fri, 13 Feb 2015 14:47:10 -0500 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id D674C5DE5D8; Fri, 13 Feb 2015 14:47:08 -0500 (EST) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id D32055DE58D; Fri, 13 Feb 2015 14:47:08 -0500 (EST) To: Stan Shebs cc: "gdb@sourceware.org" Subject: filtering traceframes (was: Re: possible QTFrame enhancement) In-reply-to: <54405367.9030000@earthlink.net> References: <4250.1411074396@usendtaylorx2l> <13378.1413479010@usendtaylorx2l> <5440356E.3080705@redhat.com> <54405367.9030000@earthlink.net> Comments: In-reply-to Stan Shebs message dated "Thu, 16 Oct 2014 19:23:19 -0400." Date: Fri, 13 Feb 2015 19:50:00 -0000 Message-ID: <17376.1423856828@usendtaylorx2l> From: David Taylor X-EMM-MHVC: 1 X-RSA-Classifications: DLM_1, public X-Sentrion-Hostname: mailuogwprd03.lss.emc.com X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00025.txt.bz2 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