This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: MI tests: tolerate prototypes
[Jason, the reason I CC'd you is down near the bottom.]
On Tue, Feb 05, 2002 at 06:56:04PM -0500, Jim Blandy wrote:
>
> Daniel Jacobowitz <drow@mvista.com> writes:
> > On Sun, Feb 03, 2002 at 04:06:09PM -0500, Jim Blandy wrote:
> > >
> > > Sun Feb 3 12:56:38 2002 Jim Blandy <jimb@seadog.cygnus.com>
> > >
> > > * mi-var-child.exp ("get children of struct_declarations", "get
> > > children of struct_declarations.s2.u2.u1s2", "get children of
> > > weird"): Tolerate argument types when they appear in function
> > > types. (Dwarf 2 includes prototype info; STABS does not.)
> > > * mi0-var-child.exp: Same.
> >
> > Just out of curiousity... does the stabs information really not contain
> > this data, or are we just not recovering it? Could you give an
> > example?
>
> It really doesn't contain it. Check out the test program below. Here
> are the stabs for `prototyped_func' and `non_prototyped_func':
>
> .stabs "prototyped_func:F(0,1)",36,0,3,prototyped_func
> .stabs "f:p(0,14)",160,0,2,8
> .stabs "s:p(0,1)",160,0,2,12
> .stabs "s:(0,8)",128,0,2,-2
> .stabs "",36,0,0,.Lscope0-prototyped_func
>
> .stabs "non_prototyped_func:F(0,1)",36,0,11,non_prototyped_func
> .stabs "f:p(0,15)",160,0,9,8
> .stabs "s:p(0,1)",160,0,10,16
> .stabs "f:(0,14)",128,0,9,-8
> .stabs "s:(0,8)",128,0,10,-10
> .stabs "",36,0,0,.Lscope1-non_prototyped_func
>
> Notice that the types given in the functions' stabs are identical ---
> `function returning int' --- even though one has type "prototyped
> function returning int" and the other has type "non-prototyped
> function returning int".
Interestingly, for non_prototyped_func f is passed-as double and
used-as float. We seem to record this. Witness:
int func(float f, int s)
{
return 1;
}
int func2 (f, s)
float f;
int s;
{
return 2;
}
(gdb) ptype func
type = int (float, int)
(gdb) ptype func2
type = int (double, int)
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.
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.
> 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.
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.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer