This is the mail archive of the
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 <firstname.lastname@example.org> writes:
> > On Sun, Feb 03, 2002 at 04:06:09PM -0500, Jim Blandy wrote:
> > >
> > > Sun Feb 3 12:56:38 2002 Jim Blandy <email@example.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)
int func2 (f, s)
(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
> 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