This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: MI tests: tolerate prototypes
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.