This is the mail archive of the gdb-patches@sourceware.cygnus.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]

Re: [rfc] Don't convert to/from an illegal FP type


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

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