From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31717 invoked by alias); 6 Feb 2002 04:30:55 -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 31553 invoked from network); 6 Feb 2002 04:30:49 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 6 Feb 2002 04:30:49 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 22DA95E9DE; Tue, 5 Feb 2002 23:32:23 -0500 (EST) To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com, Jason Merrill Subject: Re: RFA: MI tests: tolerate prototypes References: <20020203210609.E5E035E9DE@zwingli.cygnus.com> <20020203180133.C26302@nevyn.them.org> <20020205202132.A17384@nevyn.them.org> From: Jim Blandy Date: Tue, 05 Feb 2002 20:30:00 -0000 In-Reply-To: <20020205202132.A17384@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-02/txt/msg00154.txt.bz2 Daniel Jacobowitz writes: > 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. Oh --- I never finished my TYPE_FLAG_MAYBE_PROTOTYPED changes. GDB needs to distinguish between three kinds of function types: - This function was declared K&R style. - This function was declared with a prototype. - We can't tell. For STABS, we should produce the third kind, unless we see prototype info, in which case we can produce the second. For Dwarf 2, we only ever produce the first two. > 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. Ah, by building `prototype'-style types for all the functions, even those declared without prototypes, and using the called-as types as the prototype argument types. It'll work because, even though the type claims to be prototyped, the argument types are such that we end up doing the same promotions required by the rules for calling non-prototyped functions. > > 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. You pass them using the standard argument promotions, just as you would if I had declared it int (*non_prototyped_fptr) () which is what I actually meant to type... duh. > 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. Yes. > > 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. Yes --- I didn't think so before, but I think you're right now.