From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11404 invoked by alias); 17 Sep 2011 08:59:12 -0000 Received: (qmail 11394 invoked by uid 22791); 17 Sep 2011 08:59:10 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL,TW_BZ X-Spam-Check-By: sourceware.org Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 17 Sep 2011 08:58:51 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0LRN00E00SVZ3V00@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Sat, 17 Sep 2011 11:58:49 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.239.98]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LRN00E8DSY02O40@a-mtaout21.012.net.il>; Sat, 17 Sep 2011 11:58:49 +0300 (IDT) Date: Sat, 17 Sep 2011 13:42:00 -0000 From: Eli Zaretskii Subject: Re: [patch 00/12] entryval#2: Fix x86_64 parameters, virtual tail call frames In-reply-to: <20110916093554.GA20792@host1.jankratochvil.net> To: Jan Kratochvil Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83zki3tult.fsf@gnu.org> References: <20110913194306.GA12849@host1.jankratochvil.net> <20110916093554.GA20792@host1.jankratochvil.net> 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: 2011-09/txt/msg00338.txt.bz2 > Date: Fri, 16 Sep 2011 11:35:55 +0200 > From: Jan Kratochvil > Cc: gdb-patches@sourceware.org > > not yet re-posting, just updated the branch: > archer-jankratochvil-entryval > (IIRC GIT not being friendly to you but I guess you do not need it for the > review follow-up.) I can use git repositories through Bazaar with the bzr-git plugin (but committing into git repositories is not yet supported by that plugin). > > > +set debug tailcall > > > +show debug tailcall > > > + Control display of debugging info for determining virtual tail call frames, > > > + present in inferior debug info together with the @entry values. > > > > Is it possible to rephrase this in a less mysterious way? (I cannot > > suggest a new wording because I don't understand what you meant ;-) > > maybe: > Control display of debugging info for determining virtual tail call frames. > The tail call frames GDB determines from similar inferior debug info content > like the @entry parameter values. Would it be good enough to lose the second sentence entirely? This is just a NEWS entry, so it doesn't need to go into all the details. > Added: > Entry values are normally also printed at the function parameter list > according to @xref{set print entry-values}. @ref, nor @xref. The latter produces a capitalized "See", which is inappropriate in the middle of a sentence. > the whole sentence is now: > In some cases @value{GDBN} can determine the value of function argument which > was passed by the function caller, even if the value was modified inside the > called function and therefore are different. "is different" ("argument" is single). > > > +this feature will behave in the default @code{default} setting the same way as > > ^^^^^^^ > > Lose this "default", it's redundant. > > done although I disagree a bit. The setting is called "default". That it is > the default choice is a coincidence. That's true, but consider how it will look in the manual: this feature will behave in the `default' setting the same way as ... Do you see any problems with reading and understanding this? > We could for example chooce since gdb-8.0 the default one is "compact"; The result above will be still correct English and clearly understandable even after such a change, won't it? And having a `default' setting that is not the default sounds wrong anyway... > During execution of function @code{C}, there will be no indication in > the stack frames that it was tail-called from @code{B}. How about "in the function call stack frames"? > > However, in some cases @value{GDBN} can determine that @code{C} was > > tail-called from @code{B}, and will then create fictitious call > > frame for that, with the return address set up as if @code{B} called > > @code{C} normally. > > Used as you wrote it. > > Really no nominative? ", and will then" -> ", and it will then"? I don't mind adding "it", if you think it will make the sentence more clear. > > > +@kbd{info frame} command (@pxref{Frame Info}) will indicate the tail call frame > > > +kind by text @code{tail call frame}. > > > > An example would be good. > > Put there - isn't it too long? Wrap it at or before column 72 and you are good. > > > +The detection of all the possible code path executions can find them ambiguous. > > > +There is no execution history stored (possible @ref{Reverse Execution} is never > > > +used for this purpose) and the last known caller could have reached the known > > > +callee by multiple different jump sequences. In such case @value{GDBN} still > > > +tries to show at least all the unambiguous top tail callers and all the > > > +unambiguous bottom tail calees, if any. > > > > I don't understand what this means in practice. If you show an > > example of this, I could suggest some rewording. > > This is discussed above: > > tailcall: initial: 0x400735(amb_a(int)) 0x400725(amb_b(int)) 0x40071e(amb(int)) 0x400705(amb_x(int)) 0x4006f5(amb_y(int)) 0x4006e4(amb_z(int)) > tailcall: compare: 0x400735(amb_a(int)) 0x400725(amb_b(int)) 0x400719(amb(int)) 0x400705(amb_x(int)) 0x4006f5(amb_y(int)) 0x4006e4(amb_z(int)) > tailcall: reduced: 0x400735(amb_a(int)) 0x400725(amb_b(int)) | 0x400705(amb_x(int)) 0x4006f5(amb_y(int)) 0x4006e4(amb_z(int)) But this is output only with "debug tailcall" set, isn't it? The text I commented on is describing the functionality in general, not the effect of the "debug tailcall" setting. I was asking what does "@value{GDBN} still tries to show at least all the unambiguous top tail callers and all the unambiguous bottom tail calees, if any" mean when "debug tailcall" is _not_ set? Are you talking about output of some other command, like "bt"? if so, can you show me its output in such an ambiguous case? > It is the testcase "self: bt verbose", without `set verbose' there is: > > #0 d (i=, j=) at ./gdb.arch/amd64-entry-value.cc:34 > #1 0x0000000000400715 in self (i=) at ./gdb.arch/amd64-entry-value.cc:120 > #2 0x00000000004004d9 in main () at ./gdb.arch/amd64-entry-value.cc:191 > > and one can be curious why those were not recovered by the > `entry values' feature. With `set verbose' it will print the reason: > > #0 d (DW_OP_GNU_entry_value resolving has found function "self(int)" at 0x4006e0 can call itself via tail calls I would suggest adding this example, both without and with "verbose" setting, to the text. It makes the description much more clear and understandable. > > > +@table @code > > > +@item set debug tailcall > > > +@kindex set debug tailcall > > > +When set to on, enables tail calls analysis messages printing. It will show > > > +all the possible valid tail calls code paths it has considered. It will also > > > +print the intersection of them with the final unambiguous (possibly partial or > > > +even empty) code path result. > > > > Example, please! Some rewording is in order, but I need an example to > > suggest it. > > Again the example given for NEWS `set debug tailcall' entry above. That example, together with some explanation of the "initial", "compare", and "reduced" lines, would go a long way towards making the docs clear. Thanks.