Re: RFA: MI tests: tolerate prototypes

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Feb 05, 2002 at 11:32:22PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> 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