[linuxsh-dev] Re: Floating point problem

[kaz K. <kk...@rr...>]

"Bao C. Ha" <ba...@se...> wrote:
> (gdb) n
> 14              printf("\n status=%x\n", (int)status);
> (gdb) set archi sh4
> The target architecture is assumed to be sh4
> (gdb) p/x $fpscr
> $2 = 0x3f737871
> (gdb) n
> 
>  status=%x
> 
>  dum=%f
> ......
> CRASHED!!!
> 
> So it is the wrong FPU mode.  How do we fix it?

Before going ahead, please try
  (gdb) p/x $fpscr=0x80004
  (gdb) c
instead of p/x $fpscr to confirm the problem. If it works,
the problem must be caused by $fpscr. If this is the case,
I think that the real problem is the __fpscr_values table
in your shared libraries.

The $fpscr value problem is a long standing problem. As you
know, SH-4 FPU has no individual instructions to handle float
and double, but a mode flags in $fpscr. So the mixture of
the float and double arithmetic needs the wierd switching of
$fpscr value. So, an easiest and only one easy workaround is
to use double only :-)

GCC uses __fpscr_values for this switching. This table is
the array of 32-bit words and __fpscr_values[0] is the value
for float and __fpscr_values[1] is for double. The switchig
is done by the load from these values to $fpscr. There are
versions of compiler have problems in this switching, though
this is not the case in current problem since there is no
problem with static linking.
This __fpscr_values table is in libgcc.a and defined as .comm
symbol originally. But this is not suitable for the shared
library. The __fpscr_values table is writable to set rounding
and floating exception mode, so it must be the unique entity.
The Right Thing is to put it in the shared libgcc like as
we've done it in our gcc-3.0 patch. So the 2nd workaround is
to use gcc-3.0 + our SH patch and rebuild all libraries using
it. But it isn't so easy and will cause another problems.

	kaz