Andrew Haley wrote:
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.
MIPS div instructions never trap. However I think that GCC always emits
things like this when it cannot determine that the divisor is non zero:
div $0,$17,$16
bne $16,$0,1f
nop
break 7
1:
> 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.
What are the rules? Are they more complicated then throw an
ArithmeticException when the divisor is zero?
> Q3: Will using SIGTRAP in this manner make debugging programs that
> divide things by zero very difficult to debug under gdb?
No.
I have not tried it. But I think gdb uses "break" and SIGTRAP for
breakpoints. Is it possible to get gdb to pass the signal to the
debugee, so that it could be handled by the runtime support?
