Re: Floating-point exception handling
Re: Floating-point exception handling
- Subject: Re: Floating-point exception handling
- From: "David N. Williams" <email@hidden>
- Date: Wed, 16 Sep 2009 16:04:14 -0400
- Organization: University of Michigan
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden