Re: misc/56820: Many FPE related tests fail on softfloat machines

[Martin Husemann <martin%duskware.de@localhost>]

The following reply was made to PR misc/56820; it has been noted by GNATS.

From: Martin Husemann <martin%duskware.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: misc/56820: Many FPE related tests fail on softfloat machines
Date: Wed, 11 Oct 2023 17:47:45 +0200

 On Sat, Oct 07, 2023 at 02:13:34PM +0200, Martin Husemann wrote:
 > For example with the patch applied, the following still fails:
 > 
 > Test case: lib/libc/gen/t_fpsetmask/fpsetmask_unmasked_double
 > Duration: 21.741232 seconds
 > Termination reason
 > 
 > FAILED: Test program received signal 8 (core dumped)
 > Standard error stream
 > 
 > Test program crashed; attempting to get stack trace
 > [New process 9660]
 > Core was generated by `t_fpsetmask'.
 > Program terminated with signal SIGFPE, Arithmetic exception.
 > #0  0x752ea0f4 in sigqueueinfo () from /usr/lib/libc.so.12
 > #0  0x752ea0f4 in sigqueueinfo () from /usr/lib/libc.so.12
 > #1  0x752e84c2 in _softfloat_float_raise (flags=<optimized out>) at /work/src/lib/libc/softfloat/softfloat-specialize:117
 > #2  0x752e9bc8 in __divdf3 (a=<optimized out>, b=<optimized out>) at /work/src/lib/libc/softfloat/bits64/softfloat.c:2944
 > #3  0x004011b0 in d_inv () at /work/src/tests/lib/libc/gen/t_fpsetmask.c:126
 
 This is due to the SA_RESETHAND used in the patch:
 
         sigemptyset(&set);
         sigaddset(&set, SIGFPE);
         sigprocmask(SIG_UNBLOCK, &set, NULL);
         if (sigaction(SIGFPE, NULL, &sa) == 0) {
                 if (sa.sa_handler == SIG_IGN) {
                         memset(&sa, 0, sizeof(sa));
                         sa.sa_handler = SIG_DFL;
                         sigemptyset(&sa.sa_mask);
                 } else {
                         sa.sa_flags |= SA_RESETHAND;
                 }
                 sigaction(SIGFPE, &sa, NULL);
         }
 
 
 This SA_RESETHAND is required to make SIGFPE generated while running the
 SIGFPE signal handler terminate the program. The test program
 /usr/tests/kernel/t_trapsignal tests for this in the fpe_handle_recurse
 test case. The helper program catches the signale and generates a new
 one in the handler.
 
 But for the lib/libc/gen/t_fpsetmask "unmasked" tests this causes failure:
 the test code iterates over four FP exceptions, triggers them one after
 the other, catches the signal and uses siglongjmp to go from the signal
 handler right back to the loop over the four exceptions.
 
 The first loop works fine, but the SA_RESETHAND causes the signal handler
 to be reset when we enter the signal handler:
 
 	{_sa_handler = 0x0, _sa_sigaction = 0x0}
 
 and then we siglongjmp to the main loop, restoring the signal mask, but
 not the sigaction handler. So when the loop trigers the second exception,
 the SIGFPE kills the test program.
 
 Anyone have a good idea how to deal with this?
 
 Martin