From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24593 invoked by alias); 18 Feb 2013 09:43:19 -0000 Received: (qmail 24562 invoked by uid 22791); 18 Feb 2013 09:43:17 -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 mga14.intel.com (HELO mga14.intel.com) (143.182.124.37) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 Feb 2013 09:43:06 +0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 18 Feb 2013 01:43:04 -0800 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by AZSMGA002.ch.intel.com with ESMTP; 18 Feb 2013 01:43:03 -0800 Received: from irsmsx151.ger.corp.intel.com (163.33.192.59) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 18 Feb 2013 09:42:45 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.108]) by IRSMSX151.ger.corp.intel.com ([169.254.4.144]) with mapi id 14.01.0355.002; Mon, 18 Feb 2013 09:42:44 +0000 From: "Metzger, Markus T" To: Jan Kratochvil , Eli Zaretskii CC: "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 09:43: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> In-Reply-To: <20130215190955.GA18269@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/msg00443.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Friday, February 15, 2013 8:10 PM > On Fri, 15 Feb 2013 20:05:38 +0100, Eli Zaretskii wrote: > > > It is a "backtrace" into history, not into upper frames. > > > (gdb) record backtrace > > > _IO_vsnprintf > > > _IO_vfprintf_internal > > > strchrnul > > > _IO_vfprintf_internal > > > __GI__IO_default_xsputn > > > You can see _IO_vfprintf_internal called strchrnul which then returne= d back to > > > _IO_vfprintf_internal. This is not a real "backtrace". > > > > > > I was already considering renaming the command as the term is a bit o= verloaded > > > in the debugger context. > > > > > > Maybe "record list-functions"? > > > > How about "record trace-functions"? >=20 > "trace-functions" is fine with me; we'll see what Markus says. I don't insist on the names I gave those commands, but I'd rather we had a = single word for each command.=20 Consider the existing "list" and "backtrace" commands. With the same argume= nts, they should be renamed into "list-source-lines" and "list-call-frames";-) The problem with such command names is that they are awful to type and abbreviations will be quite cryptic, e.g. "lsl" or "lcf". Jan described it nicely above: "it's a 'backtrace' into history, not into u= pper frames". The term 'backtrace' suggests it's backwards and about functions. Being a "= record" sub-command suggests it's working on the execution log. The idea of those three new commands is to provide a quick overview of the execution history at different levels of granularity. Each of those commands allows iteration similar to the "list" command. The different levels of gra= nularity are: record disassemble ......... instructions record list ....................... source lines record backtrace ............. functions I picked those terms for the record sub-commands that are associated with t= he respective level of granularity, already. It takes some practice to read the output of the above commands. Once you g= ot the hang of it, though, they give a very nice and compact overview of the r= ecorded control flow. The "record list" command will be the most difficult to make = sense of in the beginning. The "btrace list" command that Jan mentioned works on blocks, i.e. sequenti= ally executed code between two branches. This would be between "record list" and "record backtrace". I have not added a similar command to "record". 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