From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2403 invoked by alias); 27 Nov 2001 22:10:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2362 invoked from network); 27 Nov 2001 22:10:31 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by hostedprojects.ges.redhat.com with SMTP; 27 Nov 2001 22:10:31 -0000 Received: from cygnus.com (taarna.cygnus.com [205.180.230.102]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id OAA22508; Tue, 27 Nov 2001 14:10:24 -0800 (PST) Message-ID: <3C040F8D.695C4DA0@cygnus.com> Date: Thu, 15 Nov 2001 02:38:00 -0000 From: Michael Snyder Organization: Red Hat X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jim Blandy CC: gdb-patches@sources.redhat.com Subject: Re: RFA: GCC stabs don't contain prototype info References: <20011127034423.DF2B75E9D8@zwingli.cygnus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00298.txt.bz2 Message-ID: <20011115023800.Fa1eOzTS9voh9078XZwroYm6i2Kkp-TX0NzmDX-MQTA@z> Jim Blandy wrote: > > This comes as a bit of a surprise to me, but it seems that stabs > generated by GCC don't indicate whether a given function was defined > with a prototype or not. The argument types should appear after the > return types, each preceded by a semicolon, but for the following > input program: > > int foo (int a, float b) { return a + b; } > > `gcc -save-temps -O2 -g -c' generates the following relevant stabs: > > .stabs "int:t(0,1)=r(0,1);0020000000000;0017777777777;",128,0,0,0 > .stabs "float:t(0,12)=r(0,1);4;0;",128,0,0,0 > .stabs "foo:F(0,1)",36,0,1,foo > .stabs "a:P(0,1)",64,0,1,8 > .stabs "b:P(0,12)",64,0,1,9 > .stabs "",36,0,0,.LLscope0-foo > .stabs "",100,0,0,.Letext > > There is no no prototype info here. There's no way for GDB to know > that the function expects its second argument to be passed as a float, > not promoted to a double, as the K&R-style rules specify. Yes, this is an old, old issue. The test (float2) in callfuncs.exp was designed to reveal this problem. Unfortunately a few years ago somebody went thru callfuncs.c and protoized all of the functions, thus defeating this test. I've recently restored it, which is why you may be suddenly seeing the fails again. > > Thus: > > 2001-11-26 Jim Blandy > > * gdb.base/callfuncs.exp: The stabs generated by GCC don't tell us > whether functions are prototyped or not, so we can't possibly pass > arguments to t_float_values2 properly. Yep, that's why it's there. I suppose xfailing it is reasonable, if there is no hope of it ever being fixed. > > Index: gdb/testsuite/gdb.base/callfuncs.exp > =================================================================== > RCS file: /cvs/cvsfiles/devo/gdb/testsuite/gdb.base/callfuncs.exp,v > retrieving revision 1.46 > diff -c -r1.46 callfuncs.exp > *** gdb/testsuite/gdb.base/callfuncs.exp 2001/11/10 00:08:23 1.46 > --- gdb/testsuite/gdb.base/callfuncs.exp 2001/11/27 03:24:59 > *************** > *** 142,147 **** > --- 142,150 ---- > gdb_test "p t_float_values(float_val1,-2.3765)" " = 1" > > # Test passing of arguments which might not be widened. > + # Under stabs, GCC doesn't tell us whether the function was > + # prototyped or not. > + if {$gcc_compiled} { setup_xfail_format "stabs" } > gdb_test "p t_float_values2(0.0,0.0)" " = 0" > > # Although PR 5318 mentions SunOS specifically, this seems > *************** > *** 152,158 **** > --- 155,166 ---- > setup_xfail "alpha-dec-osf2*" "i*86-*-sysv4*" 5318 > } > } > + > + # Under stabs, GCC doesn't tell us whether the function was > + # prototyped or not. > + if {$gcc_compiled} { setup_xfail_format "stabs" } > gdb_test "p t_float_values2(3.14159,float_val2)" " = 1" > + > gdb_test "p t_small_values(1,2,3,4,5,6,7,8,9,10)" " = 55" > > gdb_test "p t_double_values(0.0,0.0)" " = 0" > *************** > *** 289,294 **** > --- 297,304 ---- > } > } > } > + > + get_debug_format > > # Make sure that malloc gets called and that the floating point unit > # is initialized via a call to t_double_values.