From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21369 invoked by alias); 6 Feb 2002 01:21:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21303 invoked from network); 6 Feb 2002 01:21:37 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 6 Feb 2002 01:21:37 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16YGmC-0005Cj-00; Tue, 05 Feb 2002 20:21:32 -0500 Date: Tue, 05 Feb 2002 17:21:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb-patches@sources.redhat.com, Jason Merrill Subject: Re: RFA: MI tests: tolerate prototypes Message-ID: <20020205202132.A17384@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb-patches@sources.redhat.com, Jason Merrill References: <20020203210609.E5E035E9DE@zwingli.cygnus.com> <20020203180133.C26302@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2002-02/txt/msg00147.txt.bz2 [Jason, the reason I CC'd you is down near the bottom.] On Tue, Feb 05, 2002 at 06:56:04PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > On Sun, Feb 03, 2002 at 04:06:09PM -0500, Jim Blandy wrote: > > > > > > Sun Feb 3 12:56:38 2002 Jim Blandy > > > > > > * mi-var-child.exp ("get children of struct_declarations", "get > > > children of struct_declarations.s2.u2.u1s2", "get children of > > > weird"): Tolerate argument types when they appear in function > > > types. (Dwarf 2 includes prototype info; STABS does not.) > > > * mi0-var-child.exp: Same. > > > > Just out of curiousity... does the stabs information really not contain > > this data, or are we just not recovering it? Could you give an > > example? > > It really doesn't contain it. Check out the test program below. Here > are the stabs for `prototyped_func' and `non_prototyped_func': > > .stabs "prototyped_func:F(0,1)",36,0,3,prototyped_func > .stabs "f:p(0,14)",160,0,2,8 > .stabs "s:p(0,1)",160,0,2,12 > .stabs "s:(0,8)",128,0,2,-2 > .stabs "",36,0,0,.Lscope0-prototyped_func > > .stabs "non_prototyped_func:F(0,1)",36,0,11,non_prototyped_func > .stabs "f:p(0,15)",160,0,9,8 > .stabs "s:p(0,1)",160,0,10,16 > .stabs "f:(0,14)",128,0,9,-8 > .stabs "s:(0,8)",128,0,10,-10 > .stabs "",36,0,0,.Lscope1-non_prototyped_func > > Notice that the types given in the functions' stabs are identical --- > `function returning int' --- even though one has type "prototyped > function returning int" and the other has type "non-prototyped > function returning int". Interestingly, for non_prototyped_func f is passed-as double and used-as float. We seem to record this. Witness: int func(float f, int s) { return 1; } int func2 (f, s) float f; int s; { return 2; } (gdb) ptype func type = int (float, int) (gdb) ptype func2 type = int (double, int) I only see testsuite failures dealing with non-prototyped functions because of DWARF-2. GCC/Stabs marks non-prototyped functions as having the post-promotion type; GCC/Dwarf-2 marks the real type of the function and removes the DW_AT_prototyped attribute. So it appears to me that the type of a function that we detect will be the type-to-be-called-as for stabs. For DWARF-2 it will be the declared type, and we will have the DW_AT_prototyped attribute to tell us if coercion is necessary. I don't know how other debug readers will behave, since those are the only two I'm familiar with. Nor do I know how Sun's compiler (for instance) emits stabs in this case - but the stabs texinfo document suggests that it behaves the same. We should be able to use this to get all cases right even without more information. > If you look at the stabs for the two function pointer variables, you > can see the problem even more easily: > > .stabs "prototyped_fptr:G(0,23)=*(0,24)=f(0,1)",32,0,15,0 > .stabs "non_prototyped_fptr:G(0,23)",32,0,16,0 > > The type info here for these functions is identical, even though you > couldn't even pass the `f' argument to (*prototyped_fptr) correctly > given this info. (You'd pass a double, while it expects a float.) How could you pass it at all? That says 'function returning int'! It doesn't say what the arguments to the function are. Also, your example says: > int (*prototyped_fptr) (float f, short s); > int (*non_prototyped_fptr) (float f, short s); Of course those have the same types. But even if you differentiate them, stabs only describes function pointers by their return type. Quite regrettable; it must be a GCC bug or at least limitation. This is the one that's actually related to the patch at the start of this thread. I think that the patch is fine, but that this should go on our list of things to fix in GCC's debug output. Jason, I don't suppose you could look at it? The 'right' thing to do would be to emit the Sun extension for any prototyped function or properly declared (prototyped, essentially) function pointer. > Anyway, there's a standard syntax for prototyped function types > defined in the STABS manual. GDB even reads it. If GCC would just > emit it, things would be better. Yes, certainly. But I think it should only cause cosmetic, not functional, differences for functions. For function pointers we need more information but for functions we should have enough information to call them correctly. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer