From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 511 invoked by alias); 14 Mar 2009 10:22:17 -0000 Received: (qmail 503 invoked by uid 22791); 14 Mar 2009 10:22:17 -0000 X-SWARE-Spam-Status: No, hits=-0.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_37,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout5.012.net.il (HELO mtaout5.012.net.il) (84.95.2.13) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 14 Mar 2009 10:22:07 +0000 Received: from conversion-daemon.i_mtaout5.012.net.il by i_mtaout5.012.net.il (HyperSendmail v2004.12) id <0KGH00600REC8000@i_mtaout5.012.net.il> for gdb-patches@sourceware.org; Sat, 14 Mar 2009 12:21:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([77.127.228.91]) by i_mtaout5.012.net.il (HyperSendmail v2004.12) with ESMTPA id <0KGH0021BRG33BD1@i_mtaout5.012.net.il>; Sat, 14 Mar 2009 12:21:40 +0200 (IST) Date: Sat, 14 Mar 2009 10:45:00 -0000 From: Eli Zaretskii Subject: Re: [patch] Fix `return' of long/long-long results with no debuginfo In-reply-to: <20090313171134.GA4396@host0.dyn.jankratochvil.net> To: Jan Kratochvil Cc: brobecker@adacore.com, tromey@redhat.com, mark.kettenis@xs4all.nl, drow@false.org, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: References: <200902112237.n1BMbbOb006035@brahms.sibelius.xs4all.nl> <20090211225012.GA28683@host0.dyn.jankratochvil.net> <200903042129.n24LTUKa000770@brahms.sibelius.xs4all.nl> <20090309015510.GA28986@host0.dyn.jankratochvil.net> <200903092233.n29MXEfG019900@brahms.sibelius.xs4all.nl> <20090311163024.GA25708@adacore.com> <20090311205901.GB25708@adacore.com> <20090313171134.GA4396@host0.dyn.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: 2009-03/txt/msg00226.txt.bz2 > Date: Fri, 13 Mar 2009 18:11:35 +0100 > From: Jan Kratochvil > Cc: Tom Tromey , Mark Kettenis , drow@false.org, gdb-patches@sourceware.org > > gdb/doc/ > 2009-03-13 Jan Kratochvil > > * gdb.texinfo (Returning): New description for missing debug info. Thanks, this part is approved, provided that you add the missing punctuation and clarify the text, as indicated below. > + The concrete registers assignment depends on the OS ABI and the > +type being returned by the selected stack frame. I'm not sure the reader will understand why this sentence is here. Perhaps it is important to have this note, but then please add some (apparently missing) text that would explain how register assignment is relevant to the issue at hand. Maybe you need to begin with the normal case, where both the caller and the callee have debug info, and take it from there to the two less obvious cases. See below. > +As the selected stack frame function may not have its debug info available in > +such cases @value{GDBN} needs to find out the type to return from user. For ^ Missing comma. > +example typing @samp{return -1} with its implicit type @code{int} would set ^ Missing comma. Also, please use @kbd{return -1} instead of @samp, as you are describing keyboard input. > would set > +only a part of a @code{long long int} result for a debug info less function. I think it is better to talk about more general mismatch of an `int' and the function's return type, because the "partial fill" case is just a special case, and even then only on some platforms. That's assuming that there is indeed a place for generalization: would your first example still work the same if the return value of the function were `double'? > +Therefore the implicit return type is accepted for debug info featuring > +functions as in this case: > + > +@smallexample > +Breakpoint 1, func () at gdb.base/return-nodebug.c:29 > +29 return 31; > +(@value{GDBP}) return -1 > +Make func return now? (y or n) y > +#0 0x004004f6 in main () at gdb.base/return-nodebug.c:43 > +43 printf ("result=%lld\n", func ()); > +(@value{GDBP}) > +@end smallexample > + > +But for functions missing their debug info the user is required to specify the > +return type by an appropriate cast explicitely: ^^^^^^^^^^^ A typo. Anyway, this is confusing: the paragraph begins by talking about functions without debug info, but then you give an example for a function _with_ debug info, and say "Therefore", as if the example where GDB does accept incomplete spec of the return value somehow _follows_ from the immediately preceeding discussion. I would begin with describing the normal case explicitly, before the text you wrote. Something like: Normally, both the selected stack frame and the one above it have debug info. @value{GDBN} uses the debug info when the value of @var{expression} does not have an explicit data type. For example, if you type @kbd{return -1}, and the function in the current stack frame is declared to return a @code{long long int}, @value{GDBN} transparently converts the implicit @code{int} value of -1 into a @code{long long int}: However, if the selected stack frame does not have a debug info, e.g., if the function was compiled without debug info, ... and now describe the use-case you are talking about and give your second example. OK?