On Fri, 11 Jun 2004, David Daney wrote: > I guess I didn't fully read the comment above this section of code. > > /* > * There is the ancient bug in the MIPS assemblers that the break > * code starts left to bit 16 instead to bit 6 in the opcode. > * Gas is bug-compatible ... > */ > > I am using gcc-3.3.1/binutils-2.15. With this toolchain, I get break > instructions that comply with the MIPS documentation for break instructions: Well, I did some research and I'm afraid it dates back to a commit from 2000-12-01, when a different interpretation of "break" was introduced for the MIPS32/64 ISA. So the interpretation of the "break" instruction depends on the "-march" setting and moreover, only for instructions requested explicitly. For ones emitted implicitly as a result of division and multiplication macros, the interpretation is always the "traditional" one (the "c" vs the "B" code). > 00000000 <do_div>: > 0: 3c1c0000 lui gp,0x0 > 4: 279c0000 addiu gp,gp,0 > 8: 0399e021 addu gp,gp,t9 > c: 0085001a div zero,a0,a1 > 10: 14a00002 bnez a1,1c <do_div+0x1c> > 14: 00000000 nop > 18: 000001cd break 0x7 > 1c: 00001012 mflo v0 > 20: 03e00008 jr ra > 24: 00000000 nop > > > What to do? 1. I think Linux can intercept both the "traditional" and MIPS32/64 values -- break codes are not used that extensively this would risk running out of them. The set of known ones can be seen in <asm/break.h>. However, this won't aid userland trying to interpret code (there may be none such, though). 2. Gas should definitely use the codes consistently. And it's a pity the ABI got broken -- I think another mnemonic should have been chosen for the correct implementation of "break", available to any ISA. 3. GCC should probably use traps for anything above MIPS I, anyway. Perhaps with an option, like for gas, to select the alternative. 4. Perhaps something else. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@xxxxxxxxxxxxx, PGP key available +
