Re: Expected behavior when returning from a SIGFPE handler

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Wed, 26 May 2021 19:46:57 -0700
> From: Jason Thorpe <thorpej%me.com@localhost>
> 
> 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()).

This strikes me as wrong.

The status flags (fpgetsticky, fetestexcept) don't determine whether a
floating-point operation `signals an exception' (in the language of
IEEE 754-2019); they only record whether it happened in the past.

It seems to me that if an operation [ieee754-]signals an exception
that the user has asked (with fpsetmask/feenableexcept) to be trapped,
then it should deliver a [unix-]signal, irrespective of whether some
past operation already [ieee754-]signalled an exception.

> 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.

I agree.  It would be perfectly reasonable to use a SIGFPE handler to,
say, record a history of the instructions (and perhaps stack traces)
that signalled floating-point exceptions, to give more precise
diagnostic information about where they're happening than the status
flags do -- without otherwise interrupting the flow of the program.

The default exception handling defined in IEEE 754-2019 precisely
defines what the results of the operation should be, so there's no
semantic ambiguity about what the program should observe when it
proceeds on return from the signal handler.