qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Support for NetLogic XLP Processors


From: James Hogan
Subject: Re: [Qemu-devel] Support for NetLogic XLP Processors
Date: Thu, 26 Mar 2015 09:34:14 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

On 26/03/15 09:29, Leon Alrae wrote:
> Hi Duarte,
> 
> On 25/03/2015 23:54, Duarte Silva wrote:
>> On Wednesday 25 March 2015 17:33:59 Leon Alrae wrote:
>>> On 25/03/2015 15:38, Duarte Silva wrote:
>>>> On Wednesday 25 March 2015 14:54:41 Leon Alrae wrote:
>>>>> On 25/03/2015 14:44, Leon Alrae wrote:
>>>>>> Hi Duarte,
>>>>>>
>>>>>> On 25/03/2015 14:20, Duarte Silva wrote:
>>>>>>> On Wednesday 25 March 2015 13:13:14 James Hogan wrote:
>>>>>>>> Hi Duarte,
>>>>>>>>
>>>>>>>> On 22/03/15 11:13, Duarte Silva wrote:
>>>>>>>>> Hi guys,
>>>>>>>>>
>>>>>>>>> I have been struggling to get some binaries compiled for NetLogic XLP
>>>>>>>>> processor to run under QEMU. I have tried a bunch of things (most
>>>>>>>>> going
>>>>>>>>> back and forth) and always get the following error message:
>>>>>>>>>
>>>>>>>>> qemu: uncaught target signal 4 (Illegal instruction) - core dumped
>>>>>>>>> Illegal instruction
>>>>>>>>>
>>>>>>>>> I tried to debug it using GDB but to no avail. Does anybody have
>>>>>>>>> ideas?
>>>>>>>>> I'm
>>>>>>>>> running QEMU 2.2.1.
>>>>>>>>
>>>>>>>> It sounds like the program had an instruction that QEMU doesn't
>>>>>>>> recognise, or doesn't think should be allowed on the current CPU which
>>>>>>>> you've set with -cpu. You might be able to find out what that
>>>>>>>>
>>>>>>>> instruction is by putting this on your qemu command line:
>>>>>>>>  -singlestep -d in_asm
>>>>>>>
>>>>>>> Hi James,
>>>>>>>
>>>>>>> thanks for the help :) I have tried with all the CPU's available. None
>>>>>>> of
>>>>>>> them worked, so I just leave it as undefined. It seems the offending
>>>>>>> instruction is "udi4".
>>>>>>>
>>>>>>> (...)
>>>>>>> IN:
>>>>>>> 0x765d1fa4:  udi4       a0,v0,zero,0x0
>>>>>>
>>>>>> According to this line you are trying to use MIPS32 CPU whereas I
>>>>>> presume you would like MIPS64R2? Please try 5KEf CPU for example which
>>>>>> is available in qemu-mips64 and qemu-mips64el QEMU binaries for big and
>>>>>> little endian respectively.
>>>>>
>>>>> I just noticed the QEMU version you are using and it doesn't contain
>>>>> 5KEf and 5KEc CPUs. Please try MIPS64R2-generic.
>>>>>
>>>>> Leon
>>>>
>>>> Hi Leon,
>>>>
>>>> have a look at the "binary-info.txt" file in the first e-Mail. It does use
>>>> the ELF magic for 32 bits ELF, not the 64 bits, that's why I get the
>>>> following:
>>>>
>>>> # chroot rootfs/ /usr/local/bin/qemu-mips64 -cpu MIPS64R2-generic /bin/sh
>>>> /bin/sh: Invalid ELF image for this architecture
>>>>
>>>> Is there a way to force the execution of the binary even if the flag
>>>> doesn't match?
>>>>
>>>> Also, if you have a look at the flags you get: noreorder, cpic, 32bitmode,
>>>> unknown CPU, o32, mips64r2. So, is it 64 bits or 32 bits ELF file?
>>>
>>> I see, this mips64r2 binary has o32 ABI. It indeed would work in
>>> qemu-mips provided there are no mips64r2-specific instructions. I think
>>> I jumped a bit too quickly to the conclusion.
>>>
>>> QEMU's mips/disas doesn't help much in this case as it just indicates
>>> User Defined Instruction. Presumably this instruction is specific to
>>> this processor and is missing in QEMU. Are you able to get disassembly
>>> of your program and look up what is under 0x765d1fa4 address which
>>> caused the illegal instruction?
>>
>> Hi Leon,
>>
>> using IDA with a remote debug session to QEMU  I got the following 
>> disassembly 
>> (kept surrounding instructions to give some context). To IDA, this custom 
>> instruction is also unknown.
>>
>> MEMORY:765D1F90 sw      $v1, 4($v0)
>> MEMORY:765D1F94 addu    $a0, $a1
>> MEMORY:765D1F98 sw      $a0, 0($v0)
>> MEMORY:765D1F9C
>> MEMORY:765D1F9C loc_765D1F9C:
>> MEMORY:765D1F9C addiu   $a0, $s1, 0x51B0
>> MEMORY:765D1FA0 move    $v0, $zero
>> MEMORY:765D1FA0  # -----------------------
>> MEMORY:765D1FA4 .byte 0x70  # p
>> MEMORY:765D1FA5 .byte 0x82  # é
>> MEMORY:765D1FA6 .byte    0
>> MEMORY:765D1FA7 .byte 0x14
>> MEMORY:765D1FA8  # -----------------------
>> MEMORY:765D1FA8 slti    $v0, 2
>> MEMORY:765D1FAC beqz    $v0, loc_765D204C
>> MEMORY:765D1FB0 nop
>> MEMORY:765D1FB4 lw      $ra, 0x24($sp)
>> MEMORY:765D1FB8
>> MEMORY:765D1FB8 loc_765D1FB8:
>> MEMORY:765D1FB8 move    $v0, $s0
>> MEMORY:765D1FBC lw      $s1, 0x20($sp)
>> MEMORY:765D1FC0 lw      $s0, 0x1C($sp)
> 
> According to binutils this is SWAPW which belongs to XLR:
> {"swapw",          "t,b",          0x70000014, 0xfc00ffff,
> MOD_1|RD_2|LM|SM,       0,              XLR,            0,      0 },
> 
> I'm afraid you won't be able to run binaries built for NetLogic XLP
> until someone implements these instructions in QEMU.

Thanks Leon, you just beat me to it with that :-)

For reference, you can disassemble xlp specific code with objdump using
"-m mips:xlp":

$ cat test.S
.text
.word 0x70820014
$ mips-linux-gnu-gcc -o test.o -c test.S
$ mips-linux-gnu-objdump -d test.o -m mips:xlp

test.o:     file format elf32-tradbigmips


Disassembly of section .text:

00000000 <.text>:
   0:   70820014        swapw   v0,a0
        ...

Cheers
James

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]