From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2726 invoked by alias); 22 Oct 2014 18:37:09 -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 2714 invoked by uid 89); 22 Oct 2014 18:37:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS 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; Wed, 22 Oct 2014 18:37:07 +0000 Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s9MIb1LG032053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2014 14:37:03 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s9MIb1LG032053 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s9MIb1LG032053 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by maildlpprd03.lss.emc.com (RSA Interceptor); Wed, 22 Oct 2014 14:36:37 -0400 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 s9MIalY4011781; Wed, 22 Oct 2014 14:36:48 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id A86B05D6238; Wed, 22 Oct 2014 14:36:46 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id 1EF205D5236; Wed, 22 Oct 2014 14:36:46 -0400 (EDT) To: Stan Shebs cc: "gdb@sourceware.org" Subject: 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: Wed, 22 Oct 2014 18:37:00 -0000 Message-ID: <19155.1414003006@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: 2014-10/txt/msg00089.txt.bz2 Stan Shebs wrote: > On 10/16/14, 2:15 PM, Pedro Alves wrote: > > On 10/16/2014 06:03 PM, David Taylor wrote: > >> 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. Thanks. I agree. > >> QTFrame-:n > > > > This one doesn't seem to make sense. QTFrame:n means "find frame number N". > > How would that be any different? I meant to delete that one but slipped up. > "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. That to me is a reasonable semantic for it. But, it is probably not needed. > >> 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. Assuming gdbserver supports the existing QTFrame subcommands already, I would expect this to be part of the contribution. > 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. We (EMC) have a fair number of tracepoint users. We have two remote stub frontends that GDB can talk with. The two stubs share a backend (breakpoint, tracepoint, single step, expression evaluation engine). The original stub owes a lot of Cygnus Solutions, though it has been heavily modified since then. It is over 10 years old and has a number of non standard extensions. We are rewriting it and trying to use standard features whenever possible. Until recently we did not support breakpoints except as incidental to tracepoints. > 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 That *WOULD* be useful. Quite useful. I would want some additional bytecodes / operators, though. Like a way to test whether something was collected. If, to use your example, you typed: tfind collectedvar < 0 and collectedvar was only collected at some tracepoints, what should happen at tracepoints where it was not collected? If QTFrame:expr: (or something simiilar) existed, then the other QTFrame variants would effectively just be special cases. I'm not sure how efficient it would be, but it sure would be powerful. > 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. Sounds like fun. But, it is a separate project and not part of this proposal. Which do people prefer -- QTFrame-: or QTFrame:- or something else? I have two desires with regards to the remote protocol message -- . I don't want whomever reviews it to say, effectively, ``I won't approve it unless you change the remote protocol message to be ...''. I want such issues to be decided before implementation. We plan to deploy this in our stub and I don't want to have to support two syntaxes... If it is rejected based on the quality of the implementation, that it a totally separate matter. But, I want the user interface and remote protocol messages decided before implementation starts. . I want it to be a syntax that if the stub doesn't support it, it can say so (i.e., reply with an empty message), rather than reply saying it had trouble parsing the message. Other than that, I don't much care what the remote protocol message looks like. > Stan > stan@codesourcery.com David