From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24752 invoked by alias); 18 Feb 2013 13:30:21 -0000 Received: (qmail 24707 invoked by uid 22791); 18 Feb 2013 13:30:19 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Feb 2013 13:30:09 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 18 Feb 2013 05:30:07 -0800 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga002.jf.intel.com with ESMTP; 18 Feb 2013 05:29:51 -0800 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 18 Feb 2013 13:29:49 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.108]) by IRSMSX152.ger.corp.intel.com ([169.254.6.135]) with mapi id 14.01.0355.002; Mon, 18 Feb 2013 13:29:49 +0000 From: "Metzger, Markus T" To: Jan Kratochvil CC: Eli Zaretskii , "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" Subject: RE: [rfc 6/8] record disas: omit function names by default Date: Mon, 18 Feb 2013 13:30:00 -0000 Message-ID: References: <1360859352-30399-1-git-send-email-markus.t.metzger@intel.com> <1360859352-30399-7-git-send-email-markus.t.metzger@intel.com> <20130215161049.GA6219@host2.jankratochvil.net> <831uchtp4y.fsf@gnu.org> <20130215183256.GA16845@host2.jankratochvil.net> <83sj4xs8hp.fsf@gnu.org> <20130215190955.GA18269@host2.jankratochvil.net> <20130218130247.GA7250@host2.jankratochvil.net> In-Reply-To: <20130218130247.GA7250@host2.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00452.txt.bz2 > -----Original Message----- > From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-owner@sourcewa= re.org] On Behalf Of Jan Kratochvil > Sent: Monday, February 18, 2013 2:03 PM > On Mon, 18 Feb 2013 10:42:44 +0100, Metzger, Markus T wrote: > > I don't insist on the names I gave those commands, but I'd rather we ha= d a single > > word for each command. >=20 > Due to completion and GDB abbreviations I do not think a single wor= d is > required, as discussed occasionally in other cases on gdb-patches. > > > Consider the existing "list" and "backtrace" commands. With the same ar= guments, > > they should be renamed into "list-source-lines" and "list-call-frames";= -) >=20 > I see the problem in that these names already have some established meani= ng > now while you overload these names for a different functionality in btrac= e. That's the point I was trying to make with the table in my previous email. = I'd rather say I took those commands and applied them to a recorded execution history. > > Jan described it nicely above: "it's a 'backtrace' into history, not in= to upper frames". > > The term 'backtrace' suggests it's backwards and about functions. Being= a "record" > > sub-command suggests it's working on the execution log. >=20 > I got used to it now but for new users it is not obvious enough. How long did it take you? > "backtrace" is very fundamental commands of GDB with well known semantics. >=20 > Is that "record trace-functions" OK for you? "record trace-functions" sounds like it would enable tracing functions. If it has to be some two-word combination, I'd rather go with "record list-= ", i.e. "record list-functions", "record list-lines", and, for the sake of consiste= ncy, "record list-instructions". Or are you OK with "record disassemble" and "record list" and just objecting to "record backtrace"? > > The "btrace list" command that Jan mentioned works on blocks, i.e. sequ= entially > > executed code between two branches. This would be between "record list"= and > > "record backtrace". I have not added a similar command to "record". >=20 > Is this the intended final state or do you still plan updating > archer-mmetzger-btrace? I would find the "btrace ..." commands more suit= able > to be placed under "record btrace ...", so that one has all the available > "record btrace ..." commands at one place with "record btrace ". >=20 > There can be "btrace ..." ones as aliases to them (although I do not thin= k it > is needed, user can create an alias using the 'alias' command easily if > needed). I intend to remove the "btrace" command and all its sub-commands. I just ke= pt them so people can compare them with the new "record" commands. Regarding "brace list" I do not plan to add a corresponding "record" comman= d. Regards, Markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052