site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Organization: University of Michigan User-agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Terry Lambert wrote:

Your handler there functions by casting the void * argument to a ucontext_t pointer and then operating on the floating point state and the saved state register contents in the context structure which blows those values in the saved state on the stack. Then when the signal trampoline returns to kernel space via __sigreturn at the end of the signal function, it blows this back into the active thread state structure for the pre-trampoline thread state for the active thread from which the exception was raised, hopefully having fixed up the exception.

It is an icredibly naieve implementation, using unsupported data structures (meaning we are not going to promise to not change them on you from software update to software update), since we can safely update our exception management code in lockstep between our runtime and our kernels, and you can't, because you are unable to make simultaneous releases with no lag. We don't make those changes capraciously, but we do ocassionally make them.

The implementation is naieve because there are actually 5 possible ucontext_t layouts on the PPC ISA, and you happened to pick the G4, meaning 32 bit PPC, which is relatively the most stable possible one, and one for which there was only a single layout.

For Intel ISA, there are 5 possible layouts, and that's not including all the ones that were shipped as part of technology previews in WWDC builds (I will say that there have been at least 7).

For you to build an exception handler in a signal handler that did exactly the same thing on Intel, you would need to distinguish at runtime which layout was being used, and then patch up the right locations. For the structures to have the right offsets and members, you would likewise have to use a particular compilation environment (which I will not note here, since it could be misinterpreted as documenting it).

Finally, since some of the registers spilled could be used to thwart system security if their contents are modified, a shadow is kept in the kernel, and they are reset back to their previous values, ignoring whatever you do to them with signal stack hacking in user space. Thanks for the explanation. The handler I actually wrote doesn't do anything with ucontext_t -- it just reports which floating-point exception occurred based on the SIGFPE code returned in the siginfo_t structure, and aborts into the Forth interpreter. I quoted the Apple legacy example partly in the hope that I might have missed a more up to date version, which might allow something more useful to be done. Anything seems possible when you're ignorant. :-( Finally, if you are using x87, Intel floating point exceptions are inexact (if you are on a 754 working group, you will already be painfully aware of this fact). Because of this, delayed delivery of exceptions via signal handlers (the signal trampoline generally fires as a result of an AST set on a Mach kernel thread state structure as a result of a unix system call return after running up to the user space/kernel boundary, so it could be delayed considerably, just on Tru64 UNIX) can decouple the exception state at the time of the exception from the exception state you are trying to hack saved registers on the signal stack in order to fix up. This reinforces what I was warned about by a knowledgeable member of the group. So I will tell you what I have told others who are trying to fix up exceptions in their own runtimes: handle them as Mach exceptions, rather than using signal handlers. Okay, I'll leave that to a more ambitious implementor. As a practical matter, reporting which exception and stopping seems good enough for nondefault floating-point handling. Obviously, I can't keep you from puzzling out the bits you would need to hack to deal with runtime recognition of which of the several contexts we use in the signal stack are used in yours, since we publish both our xnu sources and our gdb changes, but if you do, you're basically on your own, and shouldn't be surprised if at some software update in the future your code stops working, for the reasons listed above. I have no desire to circumvent supported interfaces. Thanks for taking the time to provide some perspective! -- David

Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com