This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Drop IEEE FP assumption?


Hello,

	this is definitly not for GDB 5.1

GDB currently contains the code (doublest.h):

- #if HOST_BYTE_ORDER == BIG_ENDIAN
- #ifndef HOST_FLOAT_FORMAT
- #define HOST_FLOAT_FORMAT &floatformat_ieee_single_big
- #endif
- #ifndef HOST_DOUBLE_FORMAT
- #define HOST_DOUBLE_FORMAT &floatformat_ieee_double_big
- #endif
- #else /* LITTLE_ENDIAN */
- #ifndef HOST_FLOAT_FORMAT
- #define HOST_FLOAT_FORMAT &floatformat_ieee_single_little
- #endif
- #ifndef HOST_DOUBLE_FORMAT
- #define HOST_DOUBLE_FORMAT &floatformat_ieee_double_little
- #endif
- #endif

This causes GDB to assume that big-endian host has IEEE big-endian 
floating-point and a little endian host as IEEE little-endian FP. 
While, typically true, it can prove dangerous.  To quote a comment from 
valprint.c:print_floating():

   /* FIXME: kettenis/2001-01-20: The check for IEEE_FLOAT is probably
      still necessary since GDB by default assumes that the target uses
      the IEEE 754 representation for its floats and doubles.  Of
      course this is all crock and should be cleaned up.  */

I'd like to propose a fairly radical change for GDB:  When the xm file 
(or one day autoconf) fails to define the HOST floating-point formats, 
GDB defaults to the builtin software floating-point conversion routines 
instead of taking a wild guess at the host floating-point type.

I should note that it will have the effect, on some targets, of reducing 
slightly the precision of GDB's floating point arrithmetic.

Assuming this is ok, I think the types/macros ``floatformat_unknown'' 
and IEEE_FLOAT should also be put on notice.

	Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]