This is the mail archive of the
mailing list for the GDB project.
Re: RFA: MI tests: tolerate prototypes
On Tue, Feb 05, 2002 at 11:32:22PM -0500, Jim Blandy wrote:
> Daniel Jacobowitz <firstname.lastname@example.org> 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.
> > > 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