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

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

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