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