Brian Foster wrote:
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!)
When I first integrated the FP emulator into the kernel, back in 2.2.x,
I seem to
recall that someone found this problem and that I came up with a tweak
to signal
stack setup that protected the FP branch delay slot trampoline. Maybe
I'm mistaken,
or maybe the tweak was lost?
Regards,
Kevin K.
