Hello,
I've started to investigate bug #4923.
A first problem can be found after applying the following patch to the
paranoia.exe test:
https://devel.rtems.org/attachment/ticket/4923/bug-1-make-paranoia-test-fail.patch
The test fails because of the added sleep(1) at the beginning of Init()
and the CONFIGURE_STACK_CHECKER_ENABLED option which poisons the stack.
What I have been able to observe is something like this:
1) Because of the sleep(1) call, RTEMS goes through a INIT->IDLE->INIT
pair of context switches.
2) The first context switch goes through _Thread_Dispatch_direct, which
does not use an ARMv7 exception frame save/restore.
3) In _CPU_Context_switch(), the FPSCR register is not saved/restored.
4) After the 1s sleep ends, the second context switch originate with
_ARMV7M_Pendable_service_call()
5) In _ARMV7M_Pendable_service_call(), a new stack frame is generaterd
(--ef;) but only partially initalized with PC and XPSR. Everything else
on that exception frame comes from the poisonned stack.
6) Because of that, the FPU registers S0-S15 and FPSCR is loaded with
garbage.
7) This garbage is transfered to the Init task after
_CPU_Context_switch(). It does not matter for S0-S15 because they don't
need to be preserved across function calls, but for FPSCR it matters.
8) With the bogus FPSCR, pow(2.0, 1.0) returns 1.9999999999, which
breaks the paranoia FPU tests and our javascript engine :)
I might have missed something, but with the two following fixes, the
problem goes away:
1)
https://devel.rtems.org/attachment/ticket/4923/fix-1-save-and-restore-fpscr.patch
This patch explicitely save/restore the FPSCR in _CPU_Context_switch()
2)
https://devel.rtems.org/attachment/ticket/4923/fix-2-clean-initial-thread-frame.patch
This patch prevents the uninitialized or poisoned stack data to be
loaded into the VFP registers.
There is still a lot that I need to test and what I don't understand,
but what do you guys think about these 2 patches?
Thanks,
Cedric
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
