Expected behavior when returning from a SIGFPE handler

[Jason Thorpe <thorpej%me.com@localhost>]

I've been working on fixing some test case failures on the Alpha port, and I'm elbow-deep in FP-land right now.  The Alpha has a somewhat complicated FP story because it has architecture-mandated software completion for essentially anything outside the happy path in hardware, and to support that it has a virtual floating point control register called "FP_C" that is completely orthogonal to the hardware floating point control register (called "FPCR").  (Don't get me started on the "trap shadow"...)

I wrote a reduced test case program to exercise the different code paths around the DZE exception.  I can run this program in 2 different modes: DZE traps disabled (the default), DZE traps enabled.

The test program sets up a SIGFPE handler, and the handler make a copy of the siginfo, sets a global flag, and returns.  The program then does "1.0 / 0.0" and prints the result.  It checks to ensure that the DZE exception is set via fpgetsticky().  It then does "1.0 / 0.0" again, and then verifies that the SIGFPE handler was not called a second time (because I never cleared DZE with fpsetsticky()).

In the "disabled" case, the test program performs the same way on x86_64 and alpha (modulo the result of dividing by zero... on x86_64 I consistently get +inf, and on alpha sometimes I get +inf, sometimes I get 0; the AARM officially states that the results are UNPREDICTABLE).

In the "enabled" case, the alpha and x86_64 behavior differ!  On the alpha, the program progresses all the way to the end.  But on x86_64, it hangs... spinning around the SIGFPE handler.

The alpha code has, for a very long time, always advanced the PC past the faulting instruction on an arithmetic trap[1].  This, in essence, makes it behave exactly as if the exception were disabled, while still giving the handler a chance to "do something").

But the x86_64 code appears to return to the same instruction, banging its head against the proverbial wall.

It's my belief that the alpha behavior is more desirable.

Please, discuss.

[1] The PALcode, in fact, does this when delivering the exception.  The alpha FP trap handler has to do some shenanigans to find the actual faulting PC.  These shenanigans are simple (PC += 4) for EV6 and later CPUs, and somewhat complicated for pre-EV6 (which has to deal with the "trap shadow").  In any case, even when software completion is not possible because trap shadow rules were violated by either the program-writer or the compiler, you're pretty much guaranteed to not execute the faulting instruction again.

-- thorpej