data corruption: gcc/powerpc implicit use of FP registers

[Till Straumann]

Joel Sherrill <joel at OARcorp.com> wrote:
> Till Straumann wrote:
> 
>> It seems that some versions of gcc (gcc-3.2, gcc-3.4 but not gcc-4.0.2)
>> implicitely use floating-point registers, at least for 64bit data
>> moves. This means that an integer-only task doing things like
>>
>>   struct x { unsigned a,b; };
>>
>>   void cpx(struct x *p1, struct x *p2)
>>   {
>>     *p1 = *p2;
>>   }
>>
>> may suffer from corruption by a FP task being scheduled while the
>> copy is in process.
>>
>> There is an old thread (10/2002) on the gcc mailing list discussing
>> a '-no-implicit-fp' option which, however, was never adopted.
>>
>> Joel had posted that RTEMS/PPC [as a workaround] implicitely treats
>> all tasks as FP but I believe this is not true (anymore?).
> 
> 
> This is correct.  The macro CPU_ALL_TASKS_ARE_FP is FALSE in 
> cpukit/score/cpu/powerpc/rtems/score/cpu.h.
> 
>>   *Hence, I believe that data corruption
>>    is lingering out there*.
>>
>> It is quite unlikely but not impossible. (task switch to
>> a FP task must happen while integer-only task is using
>> the FPU [e.g., interrupt during 64-bit move scheduling
>> FP task]).
>>
>> -- Till
>>
>> PS:
>> I am not affected here since I enabled 'lazy FP switching' with
>> special patches to setjmp/longjmp and vfprintf and I disable
>> the FPU for integer-only tasks to catch these problems...
> 
> 
> Is code disabling the FPU in the MSR for no-FP tasks in the main CVS code?

I believe it explicitely is *not* because it was believed that the only
FPU use was a push/pop of a otherwise unused fpreg from vfprintf. If
I recall right, some people had (rightfully) warned but somehow this
was not addressed correctly.

> 
> How should we treat the FPU in general?  Enable it by default in all 
> tasks since we can't reliably predict which threads will use it?

Unfortunately, I believe the 4.6 branch must do this.

> 
> How should the Altivec be treated?
> 
>   + As another context (integer, FPU, etc).
>   + As an extension to the integer context on Altivec capable CPUs
>   + As an extension to the FPU context on Altivec capable CPUs

I'm currently thinking about this but would like not to discuss this
different issue on this thread.

> 
> I can easily see the 2nd or 3rd alternative as easily implementable.
> 
> But we need to be careful to disabled the FPU and Altivec unit on all 
> threads and ISRs which we do not expect to use it.  In that light, it 
> would be easier to take the 3rd alternative above and say that if a task 
> has the FPU enabled, then the Altivec is also enabled.
> 
> GCCs use of the FPU and Altivec registers certainly complicates things. :(

I'd like to believe that implicit FPU use has been abandoned with
gcc-4.0 (there was a comment somewhere in the past that this 'feature'
*might* be abandoned but I couldn't find anything in the change logs
or any more recent thread on the mailing list).

For 4.7 we should
  a) ask gcc maintainers if the current 4.0.2 behavior (not using FPU
     for 64bit data moves) is a bug or a feature.
  b) patch vfprintf (and probably setjmp/longjmp - c++-exception throwing
     tasks must still be FP)
  c) disable the FPU on integer-only threads to make sure we catch gcc
     generated FP instructions.
  d) Set CPU_ALL_TASKS_ARE_FP for gcc versions known to cause problems

T.

> 
> --joel