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

[Duarte Silva <duarte.silva@serializing.me>]

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)

Thanks for everything,
Duarte  

> 
> Leon