All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Alrae <leon.alrae@imgtec.com>
To: Duarte Silva <duarte.silva@serializing.me>
Cc: James Hogan <james.hogan@imgtec.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Support for NetLogic XLP Processors
Date: Thu, 26 Mar 2015 09:29:30 +0000	[thread overview]
Message-ID: <5513D17A.20807@imgtec.com> (raw)
In-Reply-To: <2216707.mRbZzWlcAX@lczc1207b1zdcs>

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.

Regards,
Leon

  reply	other threads:[~2015-03-26  9:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-22 11:13 [Qemu-devel] Support for NetLogic XLP Processors Duarte Silva
2015-03-25 11:26 ` Duarte Silva
2015-03-25 13:13 ` James Hogan
2015-03-25 14:20   ` Duarte Silva
2015-03-25 14:44     ` Leon Alrae
2015-03-25 14:54       ` Leon Alrae
2015-03-25 15:38         ` Duarte Silva
2015-03-25 17:33           ` Leon Alrae
2015-03-25 23:54             ` Duarte Silva
2015-03-26  9:29               ` Leon Alrae [this message]
2015-03-26  9:34                 ` James Hogan
2015-03-26  9:54                   ` Duarte Silva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5513D17A.20807@imgtec.com \
    --to=leon.alrae@imgtec.com \
    --cc=duarte.silva@serializing.me \
    --cc=james.hogan@imgtec.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.