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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

No.

 > 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: prims.cc 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.  :-)

Andrew.


[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux