This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: maybe prototyped
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Jim Blandy <jimb at cygnus dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sat, 01 Dec 2001 18:48:51 -0500
- Subject: Re: RFA: maybe prototyped
- References: <20011128045247.2ABFF5E9D8@zwingli.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