From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11936 invoked by alias); 16 Oct 2014 21:15:31 -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 11924 invoked by uid 89); 16 Oct 2014 21:15:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 16 Oct 2014 21:15:30 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9GLFSsn014607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 16 Oct 2014 17:15:28 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9GLFQP8015132; Thu, 16 Oct 2014 17:15:27 -0400 Message-ID: <5440356E.3080705@redhat.com> Date: Thu, 16 Oct 2014 21:15:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: David Taylor , "gdb@sourceware.org" Subject: Re: possible QTFrame enhancement References: <4250.1411074396@usendtaylorx2l> <13378.1413479010@usendtaylorx2l> In-Reply-To: <13378.1413479010@usendtaylorx2l> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-10/txt/msg00050.txt.bz2 On 10/16/2014 06:03 PM, David Taylor wrote: > In mid September I asked about a possible QTFrame / tfind enhancement. > That message generated zero responses. > > I'm hoping to get back in a day or two to our effort of adding the > setting of memory and registers at tracepoints. (It's more than half > done; but, before I finished I got yanked onto another project.) I > won't be working on implementing these proposed QTFrame / tframe > enhancements until that (and possibly some other stuff) is done. > > For the remote protocol there currently several variants of the QTFrame > message: > > QTFrame:n > QTFrame:pc:addr > QTFrame:tdp:t > QTFrame:range:start:end > QTFrame:outside:start:end > > And variants of the tfind command: > > tfind end > tfind line > tfind none > tfind outside > tfind pc > tfind range > tfind start > tfind tracepoint > > We (EMC) have a developer who runs trace experiments that generate > *LOTS* of tracepoint frames -- possibly 100,000 or more! He then likes > to find an anomaly and search *BACKWARDS* to find where things first > started going bad. That makes a lot of sense. Kind of a glaring omission, even. In a way, "tfind" is like "si/step/etc", and "tfind -r" would be like "reverse-si/step/etc". > > Other than the first QTFrame variant above -- which does no searching -- > all of the above QTFrame variants search *FORWARDS* from the current > tracepoint frame. > > I would like to propose that tfind be modified from > > tfind > to > > tfind [ -r | --reverse] > > and that the QTFrame remote protocol message have an optional `-' before > the first `:' to indicate reverse: > > QTFrame-:n This one doesn't seem to make sense. QTFrame:n means "find frame number N". How would that be any different? > QTFrame-:pc:addr > QTFrame-:tdp:t > QTFrame-:range:start:end > QTFrame-:outside:start:end I think it might make sense to put the '-' on the "how" part then, that is, after the ':', thus we'd have: QTFrame:n QTFrame:pc:addr QTFrame:-pc:addr QTFrame:tdp:t QTFrame:-tdp:t QTFrame:range:start:end QTFrame:-range:start:end QTFrame:outside:start:end QTFrame:-outside:start:end > > And for qSupported I propose: > > QTFrameReverse+ > QTFrameReverse- > > to indicate whether it is supported or not. > > Does this proposal seem reasonable to people? Would an implementation > of this stand a resonable chance of being accepted back? Yes. If it comes along with a reference implementation in gdbserver, even better. Thanks, Pedro Alves