qemu-devel.nongnu.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).