RTEMS bsps/847: data corruption on powerpc due to implicit gcc FPU utilization

[osv]

Till Straumann <strauman at slac.stanford.edu> writes:
> Ralf Corsepius wrote:
>
>>On Fri, 2005-11-04 at 04:21 +0000, RTEMS-gnats at rtems.com wrote:
>>
>>
>>>Synopsis: data corruption on powerpc due to implicit gcc FPU utilization
>>>
>>>http://www.rtems.com/cgi-bin/gnatsweb.pl?cmd=view&database=RTEMS&pr=847
>>>
>>>Unfortunately, there is no way to tell gcc not to use FP registers for
>>>other data than double/float. Unless compiling with -soft-float, gcc
>>>may use FP registers for optimization.
>>
>>>E.g., full safety would require moving all ISRs to separate
>>>compilation units and compiling those with -msoft-float!
>>>
>>>
>>This road leads to nowhere - Maintainence-wise, the rtems powerpc port
>>already is a nightmare, but this would render it absolutely
>>unmaintainable.
>>
>>
> I'm not sure if I got my point across. This is not about any fancy
> optimization I want to add or yet another library variant. I'm not
> even thinking about the multilib implications -msoft-float has.
>
> I'm talking about the fact that currently the only way of being
> certain that gcc generates rs6000/powerpc code without touching the
> FPU is -msoft-float! (Same applies to altivec).

Yes :(

>
> If we don't want to save/restore all FPU registers across interrupts
> then ISRs (and libraries they call) *must* be compiled separately with
> -msoft-float.
>
> If we dont' want to save/restore FP registers across context switches
> for all tasks then the whole kernel, the libraries it uses and all
> integer-only tasks must be compiled with -msoft-float.  [Hence the
> suggestion that on PPC all tasks should be forced to FP].

For me, disabling FPU for the duration of ISRs and for non-FP threads
(thus getting FP unavailable exception should gcc use FP) is enough to
identify and fix the problem. Not perfect but better than nothing. 

BTW, the only place where I find gcc implicitly uses FP registers is
copying of structs of size 8 (and long longs). From all the code that
comes with RTEMS itself, the only place that gives trouble is TCP stack
that does have a struct of size 8 and does copy it. I've patched the
stack to use field-by-field copy instead and now I can use it in non-FP
threads.

-- 
Sergei.