Re: RFA: MI tests: tolerate prototypes

[Jim Blandy <jimb@zwingli.cygnus.com>]

Daniel Jacobowitz <drow@mvista.com> writes:
> > GCC's STABS describe prototyped function types as if they were
> > non-prototyped function types.  However, it does provide accurate
> > pass-as types for function definitions.  This means that GDB can
> > correctly call functions under STABS if it reads function definition
> > types *as if* they were prototyped, using the pass-as types as the
> > argument types.
> > 
> > The downsides of this proposal:
> > 
> > - GDB will print function argument types incorrectly.  For example, 
> >   suppose we have the following function definition:
> > 
> >      int f (short s, float f) { return s + f; }
> > 
> >   Since the arguments' pass-as types for `s' and `f' are `int' and
> >   `double', GDB will print f's type as `int f(int, double)'.  This is
> >   weird, but it's a direct consequence of lying about the type.
> 
> Clarification: If f were not prototyped, this would be true.  So it's a
> very small price to pay, IMHO.  If it is prototyped, the pass-as type
> for f will be float, right?

Jeez, it's not like this isn't confusing enough already without my
consistently writing the opposite of what I mean.  I meant to write:

        int f (s, f) short s; float f; { return s + f; }

That function will end up with pass-as types of `int' and `double', as
required by C's rules (which are not target-specific).  It will have
use-as types of `short' and `float'.  Seeing an apparently
unprototyped function definition in STABS, GDB would (under the
proposal) construct a prototyped type with `int' and `double' as its
argument types.

The drawback here is that GDB will print the function's type as `int f
(int, double)', instead of the more correct `int f ()'.  The benefit
is that GDB will be able to call all functions for which it can find
definitions correctly --- a benefit which my `maybe-prototyped'
proposal doesn't offer.