Unexpected behaviour when catching SIGFPE on FPU-less system

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

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

Hi Kevin:

Quoted 9 lines · Kevin D. Kissell

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.

Quoted 4 lines

Regards,

Kevin K.

Commenting out the feclearexcept() line gives the same result:

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

So, it must not be the feclearexcept() causing the problem.

Looking at env[0], I see that the __fpc_csr field has a value of 1024, indicating a divide-by-zero.  As soon as that ctc1 instruction is executed, the exception is raised.  I guess that makes sense, but I don't understand why __fpc_csr has a value of 1024. When I step through the call to setjmp(), it gets set to a value of 0. In longjmp(), every other field in env[0] has the value that it was set to in the call to setjmp().

Quoted 7 lines · Shane McDonald

Looking at env[0], I see that the __fpc_csr field has a value of 1024, indicating a divide-by-zero.  As soon as that ctc1 instruction is executed, the exception is raised.  I guess that makes sense, but I don't understand why __fpc_csr has a value of 1024. When I step through the call to setjmp(), it gets set to a value of 0. In longjmp(), every other field in env[0] has the value that it was set to in the call to setjmp().

Wait, I take that back -- I was looking at the wrong env[0] variable! I can see that __fpc_csr actually does have a value of 1024 when I call setjmp(), and that's why longjmp() is setting the FCSR register to indicate divide-by-zero.  If I comment out my call to feenableexcept( FE_DIVBYZERO ), it is set to 0; if I include that call, it is set to 1024.

Looking further, I also see that I confused the Cause bits and the Enable bits of the FCSR -- the Enable divide-by-zero bit is set, not the Cause bit.  Clearly, the call to feenableexcept() must be setting that bit.  But, it no longer makes sense that an exception is raised when the FCSR register is restored to the value 1024.

When I'm inside my handler, I see the FCSR register has the value 0x8420,

OK, I think I've found the line that's causing me the problem.

Quoted 17 lines · Shane McDonald

Quoted 8 lines · Shane McDonald

Looking at env[0], I see that the __fpc_csr field has a value of 1024, indicating a divide-by-zero. As soon as that ctc1 instruction is executed, the exception is raised. I guess that makes sense, but I don't understand why __fpc_csr has a value of 1024. When I step through the call to setjmp(), it gets set to a value of 0. In longjmp(), every other field in env[0] has the value that it was set to in the call to setjmp().

Wait, I take that back -- I was looking at the wrong env[0] variable! I can see that __fpc_csr actually does have a value of 1024 when I call setjmp(), and that's why longjmp() is setting the FCSR register to indicate divide-by-zero. If I comment out my call to feenableexcept( FE_DIVBYZERO ), it is set to 0; if I include that call, it is set to 1024.

Quoted 6 lines

Looking further, I also see that I confused the Cause bits and the Enable bits of the FCSR -- the Enable divide-by-zero bit is set, not the Cause bit. Clearly, the call to feenableexcept() must be setting that bit. But, it no longer makes sense that an exception is raised when the FCSR register is restored to the value 1024.

When I'm inside my handler, I see the FCSR register has the value 0x8420, indicating that the Z bit is set in each of the Cause, Enables, and Flags fields. When longjmp() is called, it tries to write the old FCSR value of 0x400 (just the Z bit of the Enables field). In the emulation code, at lines 392 - 394 of file cp1emu.c, is the code:

    if ((ctx->fcr31 >> 5) & ctx->fcr31 & FPU_CSR_ALL_E) {
            return SIGFPE;
    }

Given the original FCSR value of 0x8420 and the new value to set of 0x400, the Z bit of the Cause field is still set, and as a result, the above code causes the SIGFPE exception to be thrown.

Now that I've figured that out, I have to admit that I don't know if the emulator has the proper behaviour, or if not, what the fix is. Kevin, what do you think?

Quoted 10 lines · Shane McDonald

When I'm inside my handler, I see the FCSR register has the value 0x8420, indicating that the Z bit is set in each of the Cause, Enables, and Flags fields.  When longjmp() is called, it tries to write the old FCSR value of 0x400 (just the Z bit of the Enables field).  In the emulation code, at lines 392 - 394 of file cp1emu.c, is the code:

    if ((ctx->fcr31 >> 5) & ctx->fcr31 & FPU_CSR_ALL_E) { return SIGFPE;
    }

Quoted 4 lines

Given the original FCSR value of 0x8420 and the new value to set of 0x400, the Z bit of the Cause field is still set, and as a result, the above code causes the SIGFPE exception to be thrown.

That's not how I read the code.  If ctx->fcr31 is 0x400, then the result of the AND should be zero.

In the following chunk of code from cp1emu.c:

value gets set to an initial value of 0x400, and ctx->fcr31 comes in with an initial value of 0x8420.
By the time we hit the if statement around the return SIGFPE, ctx->fcr31 has been set to 0x8400, not the 0x400 I implied.

Nevertheless, that's not the problem.

You've given me some good pointers
for where to begin searching for the problem.

If anyone out there has a verification suite they can run on the emulator, that would be much appreciated!

What we used to use was what I *thought* was an old public domain program whose name was an English word that had something to do with being exacting. Googling with obvious keywords didn't turn it up.

Quoted 4 lines · Kevin D. Kissell

What we used to use was what I *thought* was an old public domain program whose name was an English word that had something to do with being exacting. Googling with obvious keywords didn't turn it up.

Is it paranoia by any chance? Paranoia is available as single files at:

http://www.math.utah.edu/~beebe/software/ieee/paranoia.c
http://www.math.utah.edu/~beebe/software/ieee/paranoia.h

It's ages that soembody last ran it but last known status is that there were no paranoia fault.

Quoted 3 lines · Kevin D. Kissell

What we used to use was what I *thought* was an old public domain program whose name was an English word that had something to do with being exacting.  Googling with obvious keywords didn't turn it up.

Is it paranoia by any chance?  Paranoia is available as single files at:

 http://www.math.utah.edu/~beebe/software/ieee/paranoia.c
 http://www.math.utah.edu/~beebe/software/ieee/paranoia.h

Quoted 10 lines · Ralf Baechle

Quoted 3 lines · Kevin D. Kissell

What we used to use was what I *thought* was an old public domain program whose name was an English word that had something to do with being exacting.  Googling with obvious keywords didn't turn it up.

Is it paranoia by any chance?  Paranoia is available as single files at:

 http://www.math.utah.edu/~beebe/software/ieee/paranoia.c
 http://www.math.utah.edu/~beebe/software/ieee/paranoia.h

You also need

http://www.math.utah.edu/~beebe/software/ieee/args.h

Ran fine on:
 - Toshiba RBTX4927 (with FPU :-)
 - Mikrotik RouterBOARD 150 (without FPU), using an older 2.6.x OpenWRT kernel

Quoted 14 lines · Geert Uytterhoeven

Quoted 10 lines · Ralf Baechle

Quoted 3 lines · Kevin D. Kissell

What we used to use was what I *thought* was an old public domain program whose name was an English word that had something to do with being exacting.  Googling with obvious keywords didn't turn it up.

Is it paranoia by any chance?  Paranoia is available as single files at:

 http://www.math.utah.edu/~beebe/software/ieee/paranoia.c
 http://www.math.utah.edu/~beebe/software/ieee/paranoia.h

You also need

Quoted 5 lines

http://www.math.utah.edu/~beebe/software/ieee/args.h

Ran fine on:
 - Toshiba RBTX4927 (with FPU :-)
 - Mikrotik RouterBOARD 150 (without FPU), using an older 2.6.x OpenWRT kernel

and runs into an endless loop around line 806 when built with a softfloat toolchain (gcc-4.4.3).

Quoted 14 lines · Geert Uytterhoeven

Quoted 10 lines · Ralf Baechle

Quoted 3 lines · Kevin D. Kissell

What we used to use was what I *thought* was an old public domain program whose name was an English word that had something to do with being exacting. Googling with obvious keywords didn't turn it up.

Is it paranoia by any chance? Paranoia is available as single files at:

http://www.math.utah.edu/~beebe/software/ieee/paranoia.c
http://www.math.utah.edu/~beebe/software/ieee/paranoia.h

You also need

Quoted 5 lines

http://www.math.utah.edu/~beebe/software/ieee/args.h

Ran fine on:
- Toshiba RBTX4927 (with FPU :-)
- Mikrotik RouterBOARD 150 (without FPU), using an older 2.6.x OpenWRT kernel

and runs into an endless loop around line 806 when built with a softfloat toolchain (gcc-4.4.3).

Quoted 16 lines · Manuel Lauss

Quoted 14 lines · Geert Uytterhoeven

Quoted 4 lines · Ralf Baechle

Is it paranoia by any chance? Paranoia is available as single files at:

http://www.math.utah.edu/~beebe/software/ieee/paranoia.c
http://www.math.utah.edu/~beebe/software/ieee/paranoia.h

You also need

http://www.math.utah.edu/~beebe/software/ieee/args.h

Ran fine on:
- Toshiba RBTX4927 (with FPU :-)
- Mikrotik RouterBOARD 150 (without FPU), using an older 2.6.x
OpenWRT kernel

Quoted 3 lines

and runs into an endless loop around line 806 when built with a softfloat toolchain (gcc-4.4.3).

From the point of view of this specific problem, using a softfloat toolchain isn't what you want to do.

Quoted 3 lines · Shane McDonald

In the following chunk of code from cp1emu.c:

[snip]

Quoted 6 lines

value gets set to an initial value of 0x400, and ctx->fcr31 comes in with an initial value of 0x8420.
By the time we hit the if statement around the return SIGFPE, ctx->fcr31 has been set to 0x8400, not the 0x400 I implied.

Ah, well that would rather change things, and you *would* get an exception there. As written, the code doesn't seem to allow the pending exception (.._X) bits to be cleared by the CTC.

Quoted 2 lines

Nevertheless, that's not the problem.

Maybe it is. I don't have my MIPS specs handy anymore, but just what is supposed to clear a pending exception bit in a real FPU?

Quoted 3 lines · Shane McDonald

In the following chunk of code from cp1emu.c:

[snip]

Quoted 6 lines

value gets set to an initial value of 0x400, and ctx->fcr31 comes in with an initial value of 0x8420.
By the time we hit the if statement around the return SIGFPE, ctx->fcr31 has been set to 0x8400, not the 0x400 I implied.

Ah, well that would rather change things, and you *would* get an exception there. As written, the code doesn't seem to allow the pending exception (.._X) bits to be cleared by the CTC.

Quoted 2 lines

Nevertheless, that's not the problem.

Maybe it is.