On 9/24/19 3:31 PM, Libo Zhou wrote: >>> I would start by using the QEMU gdbstub to connect a >>> MIPS-aware gdb. Then when the SIGILL arrives you can see >>> what instruction the guest program was trying to execute. > >> Just tried it and found something interesting. >> I connected gdb-multiarch to QEMU gdbstub. gdb-multiarch's architecture was >> set to mips:3000 automatically (and Wikipedia says r3k uses MIPS-I). > >> When I did 'layout asm', and compared the instructions displayed against >> test.s generated by my mipsel-linux-unknown-gcc, they appeared to be a >> little bit different. > >> The 'store word' instruction in test.s is shown as a hex '0x7f......(don't >> remember the rest)'; >> 'load word' is shown as '0x5f......'; >> 'load immediate' is seen as 'addi'; >> 'j' as 'jr'; > >> When I single-stepped the instructions, the SIGILL was thrown immediately >> after the first unrecognized 0x7f......, which is supposed to be a store >> word (sw). > >> Hence, can I conclude that MIPS-I is not implemented in QEMU out of the box? >> Or is it possible that my compiler doesn't implement MIPS-I correctly? > > More updates about this. I just disassembled the unrecognized hex by hand, > and figured out that the store word and load word opcodes are not the same as > specified in translate.c. While the remaining fields of those unrecognized > instructions do match with the source and destination registers.
What is your compiler/assembler versions (on both machines you used)?
