Re: RFA: MI tests: tolerate prototypes

[Daniel Jacobowitz <drow at mvista dot com>]

[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