On Wednesday 11 June 2008 15:16:56 Brian Foster wrote:
>[ ... ]
> It's [ ... ] the trampoline that has “something to do with
> FPU emulation”, which has me concerned ATM. [ ... ]
>
> The quick summary [ ... ] is the FP trampoline, which is pushed
> on the user-land stack is, unlike sigreturn, not fixed code.
> It varies on a per-instance per-thread basis. Hence the
> simple ‘vsyscall’ mechanism ((to be?) used for sigreturn)
> is inappropriate.
>
> The trampoline is only used to execute a non-FP instruction
> (<instr>) in the delay slot of an FP-instruction:
>
[ point A "before" <instr> ]
> <instr> # Non-FP instruction to execute in user-land
[ point B "after" <instr> "before" BADINST ]
> BADINST # Bad instruction forcing return to FP emulator
> COOKIE # Bad instruction (not executed) for verification
> <epc> # Where to resume execution after <instr>
[ user-land stack-pointer points here(-ish) ]
Whilst thinking about the problem and possible solutions,
it occurred to me there could be a defect in the current
trampoline: Suppose there is a signal, either at point A,
due to <instr> itself, or at point B, which is caught on
this stack, and the user-land signal-handler ‘return’s.
Doesn't the signal-handler/sigreturn stack-frame overwrite
the FP trampoline? In which case, when the signal-hander
returns, more-or-less anything could happen. (And very
unlikely to be what's wanted!)
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
