On Nov 22, 2008, at 11:56 AM, Jonas Maebe
<email@hidden> wrote:
My initial version used some form of (sig)longjmp instead of steps
5 to 7 to hand over control to our run time system, but that does
not work for fpu exceptions (at least not on PPC). The reason was
that as long as you did not return from a signal handler, fpu
exceptions remained disabled (well, you could re-enable them in the
fpscr, but the kernel dropped them on floor as soon as they
occurred again afterwards). I can't immediately find again where
this happens in xnu, but if you are interested I could try to look
it up again.
Please do; that was the specific intent of sigsetjmp/siglongjmp.
It appears to be ppc-specific (back when I first checked this code,
there was no talk yet of Intel Macs and hence no "#ifdef ppc" either).
The code is in bsd/kern/kern_sig.c and bsd/dev/ppc/unix_signal.c
In bsd/kern/kern_sig.c, there is this code in postsig() (xnu-1228.7.58):
#ifdef __ppc__
/* Needs to disable to run in user mode */
if (signum == SIGFPE) {
thread_enable_fpe(current_thread(), 0);
}
#endif /* __ppc__ */
The reason is that if you don't do this, the fpu exception will be
trigger again as soon as you enter the signal handler. Although I'm
not sure anymore why simply cleaning out fpscr wouldn't work (after
all, the fpscr at exception time is available via the signal context,
and the "high level" exception info is available via the siginfo_t*
parameter).
Then, in bsd/dev/ppc/unix_signal.c you have in sigreturn():
I.e., only here fpu exceptions are enabled again. siglongjmp() does
not go through sigreturn(), and hence does not re-enable fpu exceptions.
Jonas
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
