[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RTEMS bsps/847: data corruption on powerpc due to implicit gcc FPU utilization
- Date: Mon, 07 Nov 2005 19:03:05 +0300
- From: osv <osv at javad dot com>
- Subject: Re: RTEMS bsps/847: data corruption on powerpc due to implicit gcc FPU utilization
Till Straumann <firstname.lastname@example.org> writes:
> Ralf Corsepius wrote:
>>On Fri, 2005-11-04 at 04:21 +0000, RTEMSemail@example.com wrote:
>>>Synopsis: data corruption on powerpc due to implicit gcc FPU utilization
>>>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
> 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).
> If we don't want to save/restore all FPU registers across interrupts
> then ISRs (and libraries they call) *must* be compiled separately with
> 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