This is the mail archive of the
gdb-patches@sourceware.cygnus.com
mailing list for the GDB project.
Re: [rfc] Don't convert to/from an illegal FP type
- To: Mark Kettenis <kettenis at wins dot uva dot nl>
- Subject: Re: [rfc] Don't convert to/from an illegal FP type
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Tue, 30 May 2000 09:52:32 +1000
- CC: gdb-patches at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <39326D23.16D132D6@cygnus.com> <200005291524.RAA19143@landau.wins.uva.nl>
Mark Kettenis wrote:
> the double negative ended up with a positive - d10v's floating point
> appeared to work perfectly :-)
To expand a little on this. Prior to FBSD's fixes the test
(extract_floating()):
HOST_LONG_DOUBLE_FORMAT == TARGET_LONG_DOUBLE_FORMAT
was being made where both were ``&floatformat_unknown''. I'm still
trying to figure out how this worked as the d10v is BE while i386 is LE.
Fixing FreeBSD made things worse - the test failed so the code instead
started calling:
floatformat_to_doublest (TARGET_LONG_DOUBLE_FORMAT, addr, &dretval);
i.e. floatformat_to_doublest (&floatformat_unknown, addr, &dretval);
not sure what happened next but ``22. .LT. 44.'' started failing!
(The d10v, which is into extreme data types, has sizeof(float) ==
sizeof(double) == 4 and sizeof(long double)==8)
> Andrew, have you seen the following comment in defs.h:
>
> /* This is used to indicate that we don't know the format of the floating point
> number. Typically, this is useful for native ports, where the actual format
> is irrelevant, since no conversions will be taking place. */
>
> extern const struct floatformat floatformat_unknown;
Yes, that was in part causing the problem :-(
> Most i386 targets set TARGET_LONG_DOUBLE_FORMAT to the real format now
> regardless whether they're used as part of a native port, which means
> that this convention isn't very useful anymore. But your change kills
> the convention for the whole of GDB. That may actually be a good
> thing (since right now cross-debuggers might think host and target
> `long double' formats are identical when they're not), but it might
> also cause some regressions (i.e. on native ports that support `long
> double' but don't explicitly specify the format).
Hmm, yes, the convention is definitely dangerous for cross-debuggers
(per the above). I'm going to have to find a way of not ``breaking''
existing native ports (or at least move them forward). :-/
At a guess something horrendous like:
{HOST,TARGET}_LONG_DOUBLE_FORMAT
if TARGET_LONG_DOUBLE_BIT == TARGET_DOUBLE_BIT
TARGET_DOUBLE_FORMAT
else if TARGET_LONG_DOUBLE_BIT == floatformat_i387_ext.totalsize
&floatformat_i387_ext
else
&floatformat_unknown
sigh.
Thanks for the comments,
Andrew