[Top] [All Lists]

[RFC] MIPS division by zero and libgcj...

To: David Daney <>
Subject: [RFC] MIPS division by zero and libgcj...
From: Andrew Haley <>
Date: Thu, 10 Jun 2004 20:31:47 +0100
In-reply-to: <>
Original-recipient: rfc822;
References: <>
David Daney writes:
 > It appears that gcc configured for mipsel-linux will execute a "break 7" 
 > instruction on integer division by zero.

I thought that the MIPS never generated a hardware trap for division,
but instead there was an assembler macro that did the test for
overflow, and the "div" instruction actually generates this test
inline.  Maybe do a disassembly to check.

 > This causes the kernel (I am using 2.4.25) to send SIGTRAP.
 > Gcj when configured for this platform uses the -f-use-divide-subroutine 
 > option, causing it to never generate inline division instructions (nor 
 > the accompanying break 7), but instead call a runtime function that 
 > properly handles throwing ArithmeticException.
 > Q1:  Is this behavior (use of break 7 and SIGTRAP) part of some ABI 
 > specification?  I'll admit a bit of ignorance in this area.

See above.

 > Q2: Does anyone see any reason that libgcj should not be configured to 
 > handle the SIGTRAP and throw the ArithmeticException from the signal 
 > handler (similar to what is done on i386).

No, there's no reason not to do it.  You'll have to write some hairy
code to satisfy all the rules, though.

 > Q3: Will using SIGTRAP in this manner make debugging programs that 
 > divide things by zero very difficult to debug under gdb?


 > Q4: I appears that on the i386, a divide overflow causes SIGFPE.  Why 
 > doesn't the mips-linux kernel sent SIGFPE on "break 7"
 > Q5: in libgcj implies that we should be handling SIGFPE to do 
 > all this.  If I make these changes, won't it be a little confusing that 
 > all references to SIGFPE are really SIGTRAP?

Feel free to change the comments.  :-)


<Prev in Thread] Current Thread [Next in Thread>