Re: Expected behavior when returning from a SIGFPE handler

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

> On May 27, 2021, at 3:35 AM, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> wrote:
> 
>> 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.

I agree.  I was describing behavior the alpha port already had.  I will write a unit test for this behavior (specifically round DZE), or make sure that there is one that covers it already (there may be … I’m still peeling the onion on the alpha port…)

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

Ok, I will write a unit test that verifies this behavior.

Thanks!

-- thorpej