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.
