From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26971 invoked by alias); 1 Mar 2013 14:48:34 -0000 Received: (qmail 26958 invoked by uid 22791); 1 Mar 2013 14:48:33 -0000 X-SWARE-Spam-Status: No, hits=-8.1 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; Fri, 01 Mar 2013 14:48:24 +0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 01 Mar 2013 06:48:20 -0800 X-ExtLoop1: 1 Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by AZSMGA002.ch.intel.com with ESMTP; 01 Mar 2013 06:48:18 -0800 Received: from irsmsx151.ger.corp.intel.com (163.33.192.59) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 1 Mar 2013 14:45:35 +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; Fri, 1 Mar 2013 14:45:35 +0000 From: "Metzger, Markus T" To: Eli Zaretskii CC: "jan.kratochvil@redhat.com" , "gdb-patches@sourceware.org" Subject: RE: [PATCH 3/3] doc, record: document record changes Date: Fri, 01 Mar 2013 14:48:00 -0000 Message-ID: References: <1361808917-16934-1-git-send-email-markus.t.metzger@intel.com> <1361808917-16934-4-git-send-email-markus.t.metzger@intel.com> <838v6bhttl.fsf@gnu.org> <83vc9burfw.fsf@gnu.org> In-Reply-To: <83vc9burfw.fsf@gnu.org> 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-03/txt/msg00019.txt.bz2 > -----Original Message----- > From: Eli Zaretskii [mailto:eliz@gnu.org] > Sent: Friday, March 01, 2013 3:26 PM > > > > +"record function-call-history" prints the names of the functions > > > > +from instructions stored in the execution log. > > > > > > "prints the names of the functions called by instructions in the > > > execution log" > > > > I'm not sure whether "called" is the right term. The algorithm walks ov= er > > all instructions and collects the functions from which these instructio= ns > > originated. > > > > Example: > > > > 1 void foo (void) > > 2 { > > 3 ... > > 4 bar (); > > 5 ... > > 6 } > > > > When we record the execution of foo, there will be instructions for the > > first ..., then instructions for bar, and then instructions for the sec= ond .... > > > > The "record function-call-history" will print: > > foo.c:1-4 foo (void) > > bar.c:8-12 bar (void) > > foo.c:5-6 foo (void >=20 > This indicates that "record function-execution-history" might be a > better name. But in any case, weren't 'bar' and 'foo' called in this > example? Yes, they were called. What I have problems with is that foo was called once but we print two lines for foo, one for instructions before the call to bar and one for instructions after the return from bar. Wouldn't "called" suggest that there be only one line for foo in the above example? =20 > Your original text, "prints the names of the functions from > instructions", is confusing, since instructions don't store function > names, they store addresses and numbers. I'm not exactly happy with my formulation, either. > > > > +@kindex show record full memory-query > > > > +@item show record full memory-query > > > > > > I think it is good enough to have only one "@kindex set record" and > > > one "@kindex show record" entry (which you already have at the > > > beginning of this description), without the entries that advertise the > > > rest of the command arguments. These varieties are all described > > > together, so the multitude of index entries does not have any useful > > > effect, it just bloats the index. > > > > I just renamed the text for existing indices. Do you still want me to > > merge them? >=20 > Can you give one example of such renaming? I'm not sure I understand > what you did. There had been a target "record" that I renamed to "record-full". Then I added a new target "record-btrace" that provides similar, yet different functionality. There's a prefix-command "record" whose sub-commands operate on target record. Those sub-commands that are applicable to both targets, I left unchanged. Those sub-commands that are specific to target "record-full", I put under a new prefix-command "record full". Same for "set record" and "show record". In the documentation, there had been a @kindex show record memory-query. I changed it to @kindex show record full memory-query. > > > > +@item record function-call-history > > > > +Print function names for instructions stored in the recorded execu= tion > > > > +log. Prints one line for each sequence of instructions that is > > > > +correlated to the same function. > > > > > > Isn't the last sentence equivalent to saying > > > > > > Prints one line for each function call in the execution log. > > > > > > ? If it is equivalent, I think my suggested wording is more clear and > > > less technical. > > > > See above. >=20 > Given the example (which I think it would be good to have in the > manual), I suggest this wording instead: >=20 > Prints one line for each sequence of instructions that all belong to > the same function. That's good. Thanks! 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