Re: Replace TYPE_FLAG_PROTOTYPED with two flags

[Daniel Jacobowitz <drow at mvista dot com>]

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