From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18832 invoked by alias); 6 Feb 2002 05:48:34 -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 18700 invoked from network); 6 Feb 2002 05:48:30 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 6 Feb 2002 05:48:30 -0000 Received: from drow by nevyn.them.org with local (Exim 3.34 #1 (Debian)) id 16YKwX-0000TC-00; Wed, 06 Feb 2002 00:48:29 -0500 Date: Tue, 05 Feb 2002 21:48: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: <20020206004829.A1357@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> <20020205202132.A17384@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/msg00155.txt.bz2 On Tue, Feb 05, 2002 at 11:32:22PM -0500, Jim Blandy wrote: > > 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. So, the question becomes - do we need MAYBE_PROTOTYPED? If we accept that the types marked in stabs as parameters are promoted types, then we can simply mark stabs functions as being prototyped, and trust TYPE_FLAG_PROTOTYPED more than we do. > > > 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. > -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer