Replace TYPE_FLAG_PROTOTYPED with two flags

Replace TYPE_FLAG_PROTOTYPED with two flags

[Michael Elizabeth Chastain]

I've got these FAILs with gcc -gdwarf-2, both v2 and v3:

  FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,-2.3765)
  FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,float_val2)
  FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,float_val2)
  FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,-2.3765)

This happens because t_float_values has no prototype.  The dwarf2 reader
leaves TYPE_FLAG_PROTOTYPED clear, but later on, value_arg_coerce refuses
to trust the flag and guesses.

Indeed, Jim Blandy has been down this path recently:

  http://sources.redhat.com/ml/gdb-patches/2001-11/threads.html#00529

I am writing a new patch ("six weeks in the laboratory can often save
fifteen minutes in the library").  Instead of TYPE_FLAG_PROTOTYPED and
TYPE_FLAG_MAYBE_PROTOTYPED, I use a more solid model:

  TYPE_FLAG_PROTO_KNOWN     gdb knows whether there is a prototype 

  TYPE_FLAG_PROTO_YES       if proto_known is true, says whether there is 
			    a prototype

The dwarf and dwarf-2 readers always set TYPE_FLAG_PROTO_KNOWN,
and may set TYPE_FLAG_PROTO_YES.

The stabs reader sets TYPE_FLAG_PROTO_KNOWN when it finds an actual
prototype (an argument list in the stabs).  This does not happen with
gcc, but the comments say that it can happen with sun cc.

My big question here is: is it safe to assume that dwarf and dwarf-2
have accurate prototype information?  That is, if there is no prototype
in the debug information, can gdb really be sure that the function has
no prototype and then rely on that information?

My testing says that it can, for dwarf-2.  I haven't tested dwarf yet.
(dwarf might hit the OBSOLETE list some day but it's not OBSOLETE yet).
The stabs+ case still works because TYPE_FLAG_PROTO_KNOWN==0 behaves
like the existing code.

If it's safe to make this assumption, then I would like to proceed with
my patch, because this fixes a real bug with dwarf-2.  My goal here is
to fix bugs where dwarf-2 behaves worse than stabs+.

Michael C

Re: Replace TYPE_FLAG_PROTOTYPED with two flags

[Daniel Jacobowitz]

On Sat, Jan 04, 2003 at 11:12:53AM -0600, Michael Elizabeth Chastain wrote:
> I've got these FAILs with gcc -gdwarf-2, both v2 and v3:
> 
>   FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,-2.3765)
>   FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,float_val2)
>   FAIL: gdb.base/callfuncs.exp: p t_float_values(3.14159,float_val2)
>   FAIL: gdb.base/callfuncs.exp: p t_float_values(float_val1,-2.3765)
> 
> This happens because t_float_values has no prototype.  The dwarf2 reader
> leaves TYPE_FLAG_PROTOTYPED clear, but later on, value_arg_coerce refuses
> to trust the flag and guesses.
> 
> Indeed, Jim Blandy has been down this path recently:
> 
>   http://sources.redhat.com/ml/gdb-patches/2001-11/threads.html#00529
> 
> I am writing a new patch ("six weeks in the laboratory can often save
> fifteen minutes in the library").  Instead of TYPE_FLAG_PROTOTYPED and
> TYPE_FLAG_MAYBE_PROTOTYPED, I use a more solid model:
> 
>   TYPE_FLAG_PROTO_KNOWN     gdb knows whether there is a prototype 
> 
>   TYPE_FLAG_PROTO_YES       if proto_known is true, says whether there is 
> 			    a prototype
> 
> The dwarf and dwarf-2 readers always set TYPE_FLAG_PROTO_KNOWN,
> and may set TYPE_FLAG_PROTO_YES.
> 
> The stabs reader sets TYPE_FLAG_PROTO_KNOWN when it finds an actual
> prototype (an argument list in the stabs).  This does not happen with
> gcc, but the comments say that it can happen with sun cc.
> 
> My big question here is: is it safe to assume that dwarf and dwarf-2
> have accurate prototype information?  That is, if there is no prototype
> in the debug information, can gdb really be sure that the function has
> no prototype and then rely on that information?

Yes, it is.  GCC honors DW_AT_prototyped.

> My testing says that it can, for dwarf-2.  I haven't tested dwarf yet.
> (dwarf might hit the OBSOLETE list some day but it's not OBSOLETE yet).
> The stabs+ case still works because TYPE_FLAG_PROTO_KNOWN==0 behaves
> like the existing code.
> 
> If it's safe to make this assumption, then I would like to proceed with
> my patch, because this fixes a real bug with dwarf-2.  My goal here is
> to fix bugs where dwarf-2 behaves worse than stabs+.

I suggest reading the more recent archives before you do this. 
Particularly:
 347  N F 12/23 To gdb-patches@ ( 44K) RFC: Slay COERCE_FLOAT_TO_DOUBLE
 348  N T 12/24 Eli Zaretskii   (0.7K) `->                                                              

the which I was planning on committing this afternoon, since it
received no comments to the contrary, and that's what I said I would do
when I posted it.  It will fix the same problem.

I took a different approach than you did, as described in that message;
it's a little less cautious, but more flexible.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Replace TYPE_FLAG_PROTOTYPED with two flags

[Michael Elizabeth Chastain]

Wow, Daniel!

My observation with stabs+ matches yours: gcc does not emit a prototype,
but it does correctly mark the formal argument with 'float' or
'double'.

This ought to get a lot more cases correct, with provisions for
more kludges^H^H^H^H^H^H^H extensions if strange compilers show up.

I do think it's a bit of hack for the stabs reader to claim that all
functions are prototyped.  I think TYPE_FLAG_PROTO_KNOWN would be
more accurate.  But it's not like new broken compilers are showing up
all the time (I hope).

Someday, it will all be dwarf-2.

Michael C