More on PPC FP regs usage by integer tasks
Till Straumann
strauman at SLAC.Stanford.EDU
Thu Apr 3 23:03:08 UTC 2003
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>
More information about the users
mailing list