More on PPC FP regs usage by integer tasks

[Till Straumann]

Gregory reported recently that printf() related
newlib routines use floating point instructions
(and hence can end up crashing integer threads)
even if no true FP data is involved.

The instructions in question are usually unnecessary
save/restores of FP registers to/from the stack.

I could solve the problem by simply declaring
the critical local variable in vfprintf_r 'volatile'

I know about at least two more places which are
affected:

  - setjmp/longjmp always save/restore FP registers.
    This is a newlib issue which is easy to fix.
    Note that the fix is RTEMS specific [i.e. the
    caller needs supervisor register access;
    FP regs are only saved/restored if the FP engine
    is enabled in MSR].

  - gcc's stack unwinding machinery emits code
    saving/restoring FP registers. Probably, only
    C++ is affected. It crashes the 'cdtest' sample
    program, though...
    I don't know enough about gcc to solve this
    quickly [emitted code should check MSR_FP
    prior to saving/restoring FP registers].

This stuff is fun...

-- Till

PS: general workarounds are:
   - make all tasks FP tasks
   - don't use lazy FP context switching
     and leave the FP engine enabled all the time.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: vfprintf_fpreg_fix.diff
URL: <http://lists.rtems.org/pipermail/users/attachments/20030403/ba240ac8/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setjmp.S-ppc.diff
URL: <http://lists.rtems.org/pipermail/users/attachments/20030403/ba240ac8/attachment-0001.ksh>