This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: MI tests: tolerate prototypes

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.


> > 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]