Re: RFA: maybe prototyped

[Andrew Cagney <ac131313@cygnus.com>]

> In light of the recent discussion about stabs lossage with regards to
> prototyped functions, here's something that actually allows the debug
> readers to convey the depth of their convictions to the argument
> promotion code.
> 
> Is this a wise idea?  Who knows?  It does get rid of a FIXME, though.
> 
> 2001-11-27  Jim Blandy  <jimb@redhat.com>
> 
> Allow debug readers to indicate that a function type may or may
> 	not be prototyped.
> 	* gdbtypes.h (TYPE_FLAG_MAYBE_PROTOTYPED): New flag.
> 	(TYPE_FLAG_INCOMPLETE, TYPE_FLAG_CODE_SPACE,
> 	TYPE_FLAG_DATA_SPACE): Renumber.
> 	* stabsread.c (define_symbol): Mark all function types as `maybe
> 	prototyped', except those that have prototype info, which we
> 	continue to mark as `prototyped'.
> 	* valops.c (value_arg_coerce): Change third argument to indicate
> 	whether the function is definitely prototyped, definitely not
> 	prototyped, or perhaps prototyped.  Only consult
> 	COERCE_FLOAT_TO_DOUBLE when they are perhaps prototyped.
> 	(hand_function_call): Call value_arg_coerce appropriately.
> 

One thought on the name.

Would ``unknown'' be a better mental que than ``maybe'' - whereabouts 
unknown, prototype unknown.


The other on the macro definition (notes on a discussion we had).

There are are only three possabilities for the floating point arguments:

	o	coerced
	o	not co-erced
	o	unknown

and that is strictly determined from the debug info (and language?).

The problem is that many architectures have ignored this and instead 
instead made somewhat arbitrary decisions to always/never promote (well 
probably based on the debug info known to be used for the particular host).

Would it be better to de-multi-arch COERCE_FLOAT_TO_DOUBLE and instead 
move the code making this decision to one place - that way the decision 
was made strictly on the basis of the type/debug information?

This is a pretty significant change since it would mean that, for some 
targets, GDBs behavour might change :-/ Against that, however, is the 
benefit of finally making GDB's behavour consistent and predictable 
across all architectures.  Personally, I think the need for consistency 
and predictability is more important in this case.  We could always add 
a command that revers GDB to the old behavour (or forces a particular 
behavour for the unknown case).

Food for thought ...
Andrew