From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26722 invoked by alias); 16 Oct 2014 23:23:24 -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 26712 invoked by uid 89); 16 Oct 2014 23:23:23 -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,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: elasmtp-masked.atl.sa.earthlink.net Received: from elasmtp-masked.atl.sa.earthlink.net (HELO elasmtp-masked.atl.sa.earthlink.net) (209.86.89.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Oct 2014 23:23:22 +0000 Received: from [68.104.16.238] (helo=macbook2.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XeuO8-0006HF-A9 for gdb@sourceware.org; Thu, 16 Oct 2014 19:23:20 -0400 Message-ID: <54405367.9030000@earthlink.net> Date: Thu, 16 Oct 2014 23:23:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: possible QTFrame enhancement References: <4250.1411074396@usendtaylorx2l> <13378.1413479010@usendtaylorx2l> <5440356E.3080705@redhat.com> In-Reply-To: <5440356E.3080705@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940df53bf07bcf979549f199a3f3193fdb2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00051.txt.bz2 On 10/16/14, 2:15 PM, Pedro Alves wrote: > 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? "N from the last frame" perhaps? Although GDB does get told how many trace frames have been collected, so it can calculate "N from the end" itself. >> 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. I concur. I can't think of many other actual tracepoint users right now, so your developer gets lots of influence on how it develops further. One funky idea that occurs to me, looking at this proposal - QTFrame packet with an agent expression? The whole theory of QTFrame is to instruct the target how to find a trace frame, so if you have lots of trace frames, maybe you'd want to find by content: tfind collectedvar < 0 Compile expression to bytecode, pass it in packet, let the target agent iterate over the trace buffer and report first one found. It would be some weird byecode interpreter hackery I suppose, reading from buffer instead of live memory, but probably OK speedwise, since everything is in RAM. Stan stan@codesourcery.com