[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: illegal hardware instruction during MIPS-I ELF linux useremulation
From: |
Philippe Mathieu-Daudé |
Subject: |
Re: illegal hardware instruction during MIPS-I ELF linux useremulation |
Date: |
Tue, 24 Sep 2019 15:42:59 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 |
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)?