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

Thu Jun 10 19:49:00 GMT 2004

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,1ドルf
 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?