Re: Unexpected behaviour when catching SIGFPE on FPU-less system

["Kevin D. Kissell" <kevink@paralogos.com>]

Sorry about my previous message having escaped with no value added.

I think you need to look at just what it is that your feclearexcept() 
does.  From the strace information, it looks as if it may be that the 
FPU emulator is erroneously throwing an exception in response to some 
manipulation of the emulated FPU registers by feclearexcept(), so that 
it's taking a second FP exception within the signal handler.  That's the 
simplest explanation for the macroscopic behavior, anyway.

          Regards,

          Kevin K.

Shane McDonald wrote:
> I have run into some strange behaviour involving using the FPU
> emulation software in the MIPS kernel when trying to handle
> a divide-by-zero-caused floating point exception.
>
> I have come up with a simple test case to demonstrate this problem.
> --
> #include <stdio.h>
> #include <stdlib.h>
> #include <signal.h>
> #include <fenv.h>
> #include <setjmp.h>
>
> void fpe_handler(int);
>
> jmp_buf env;
>
> main()
> {
> 	double x;
>
> 	feenableexcept( FE_DIVBYZERO );
> 	signal( SIGFPE, fpe_handler );
>
> 	if ( setjmp( env ) == 0 )
> 	{
> 		printf( "About to try calculation\n" );
> 	
> 		x = 5.0 / 0.0;
> 		printf( "Value is %f\n", x );
> 	}
> 	else
> 	{
> 		printf( "Calculation causes divide by zero\n" );
> 	}
> }
>
> void fpe_handler(int x)
> {
> 	feclearexcept( FE_DIVBYZERO );
> 	longjmp( env, 1 );
> }
> --
>
> The program sets up to generate a SIGFPE when a divide-by-zero occurs,
> rather than setting the result to infinity.  Then, I've created a
> handler to catch the exception, and the end result is to print out
> the "Calculation causes divide by zero" message.
>
> I have two MIPS-based systems, both running Debian Etch.  One of the
> systems is a PMC-Sierra RM7035C-based system, which includes an FPU.  My
> other system is a PMC-Sierra MSP7120-based system, which does not
> include an FPU.  The RM7035C system is running the 2.6.34-rc6 kernel,
> but the MSP7120 system is running 2.6.28.
>
> When I run this program on the system with the FPU, I see the results
> that I expect to see.  The program outputs:
>
>     About to try calculation
>     Calculation causes divide by zero
>
> I see the same results when I run the program on an x86 Debian Etch system.
>
> When I run the program on the system without the FPU, I see:
>
>     About to try calculation
>     Floating point exception
>
> So, it appears that the floating point exception is not caught.
> However, when I run strace, the last few lines of output are:
>
>     old_mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ace9000
>     write(1, "About to try calculation\n"..., 25About to try calculation
>     ) = 25
>     --- SIGFPE (Floating point exception) @ 0 (0) ---
>     --- SIGFPE (Floating point exception) @ 0 (0) ---
>     +++ killed by SIGFPE +++
>
> Running it on the system with the FPU, I see:
>
>     old_mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ace5000
>     write(1, "About to try calculation\n"..., 25About to try calculation
>     ) = 25
>     --- SIGFPE (Floating point exception) @ 0 (0) ---
>     write(1, "Calculation causes divide by zero"..., 34Calculation causes divide by zero
>     ) = 34
>     exit_group(34)                          = ?
>
> After poking around for a while, and trying to account for differences
> between the systems (endianness, FPUness, kernel version), I believe the
> problem is related to the lack of FPU.  If I run the RM7035C with a
> disabled FPU (kernel parameter nofpu), I see the same results as on
> the FPU-less MSP7120.  So, I suspect this difference in behaviour
> is caused by the FPU emulation software.
>
> Now, I don't know if this is a problem, but it does seem strange.
> My level of understanding of the FPU emulation software is very low,
> so I'm not quite sure where to look.
>
> This isn't actually something that I typically do.  I noticed this
> problem when trying to understand why the Debian package "yorick"
> failed to build (see
> http://lists.debian.org/debian-mips/2010/04/msg00019.html).
>
> I'd appreciate any insight that anyone can provide.  Thanks!
>
> Shane McDonald
>
>