Hi Philippe, Peter,
In target/mips/translate_init.inc.c you can actually see that CPU_MIPS32
ultimately contains ISA_MIPS1. It's just no CPU model explicitly uses ISA_MIPS.
But I agree that if my assembly has a removed instruction then it's possible to
have an invalid machine code in my program.
As for the cross-compiler, I used a tool chain containing a compiler, an
assembler, and a linker. I produced the final ELF like this:
$ mipsel-linux-unknown-gcc -g -S test.c -o test.s
$ mipsel-linux-unknown-as -g test.s -o test.o
$ mipsel-linux-unknown-ld test.o -o test
For my qemu, I did:
$ ../configure --enable-debug --target-list=mipsel-linux-user
$ make -j4
Here are the contents of my source and generated assembly:
$ cat test.c
int main(void)
{
int a = 1;
int b = 2;
int c = a + b;
return 0;
}
$ cat test.s
.section .mdebug.abi32
.previous
.gnu_attribute 4, 3
.abicalls
.section .debug_abbrev,"",@progbits
$Ldebug_abbrev0:
.section .debug_info,"",@progbits
$Ldebug_info0:
.section .debug_line,"",@progbits
$Ldebug_line0:
.text
$Ltext0:
.align 2
.globl main
$LFB0 = .
.file 1 "test.c"
.loc 1 2 0
.cfi_startproc
.set nomips16
.ent main
.type main, @function
main:
.frame $fp,32,$31 # vars= 16, regs= 1/0, args= 0, gp= 8
.mask 0x40000000,-4
.fmask 0x00000000,0
.set noreorder
.set nomacro
addi $sp,$sp,-32
.cfi_def_cfa_offset 32
sw $fp,28($sp)
nop
nop
move $fp,$sp
.cfi_offset 30, -4
.cfi_def_cfa_register 30
.loc 1 3 0
li $2,1 # 0x1
sw $2,16($fp)
nop
nop
.loc 1 4 0
li $2,2 # 0x2
sw $2,12($fp)
nop
nop
.loc 1 5 0
lw $3,16($fp)
lw $2,12($fp)
nop
nop
add $2,$3,$2
sw $2,8($fp)
nop
nop
.loc 1 6 0
move $2,$0
.loc 1 7 0
move $sp,$fp
lw $fp,28($sp)
addi $sp,$sp,32
j $31
nop
nop
nop
nop
nop
.set macro
.end main
.cfi_endproc
$LFE0:
.size main, .-main
$Letext0:
.section .debug_loc,"",@progbits
$Ldebug_loc0:
$LLST0:
.4byte $LFB0-$Ltext0
.4byte $LFE0-$Ltext0
.2byte 0x2
.byte 0x8e
.sleb128 32
.4byte 0x0
.4byte 0x0
.section .debug_info
.4byte 0x6b
.2byte 0x2
.4byte $Ldebug_abbrev0
.byte 0x4
.uleb128 0x1
.4byte $LASF0
.byte 0x1
.4byte $LASF1
.4byte $LASF2
.4byte $Ltext0
.4byte $Letext0
.4byte $Ldebug_line0
.uleb128 0x2
.byte 0x1
.4byte $LASF3
.byte 0x1
.byte 0x1
.byte 0x1
.4byte 0x67
.4byte $LFB0
.4byte $LFE0
.4byte $LLST0
.4byte 0x67
.uleb128 0x3
.ascii "a\000"
.byte 0x1
.byte 0x3
.4byte 0x67
.byte 0x2
.byte 0x91
.sleb128 -16
.uleb128 0x3
.ascii "b\000"
.byte 0x1
.byte 0x4
.4byte 0x67
.byte 0x2
.byte 0x91
.sleb128 -20
.uleb128 0x3
.ascii "c\000"
.byte 0x1
.byte 0x5
.4byte 0x67
.byte 0x2
.byte 0x91
.sleb128 -24
.byte 0x0
.uleb128 0x4
.byte 0x4
.byte 0x5
.ascii "int\000"
.byte 0x0
.section .debug_abbrev
.uleb128 0x1
.uleb128 0x11
.byte 0x1
.uleb128 0x25
.uleb128 0xe
.uleb128 0x13
.uleb128 0xb
.uleb128 0x3
.uleb128 0xe
.uleb128 0x1b
.uleb128 0xe
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x10
.uleb128 0x6
.byte 0x0
.byte 0x0
.uleb128 0x2
.uleb128 0x2e
.byte 0x1
.uleb128 0x3f
.uleb128 0xc
.uleb128 0x3
.uleb128 0xe
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x27
.uleb128 0xc
.uleb128 0x49
.uleb128 0x13
.uleb128 0x11
.uleb128 0x1
.uleb128 0x12
.uleb128 0x1
.uleb128 0x40
.uleb128 0x6
.uleb128 0x1
.uleb128 0x13
.byte 0x0
.byte 0x0
.uleb128 0x3
.uleb128 0x34
.byte 0x0
.uleb128 0x3
.uleb128 0x8
.uleb128 0x3a
.uleb128 0xb
.uleb128 0x3b
.uleb128 0xb
.uleb128 0x49
.uleb128 0x13
.uleb128 0x2
.uleb128 0xa
.byte 0x0
.byte 0x0
.uleb128 0x4
.uleb128 0x24
.byte 0x0
.uleb128 0xb
.uleb128 0xb
.uleb128 0x3e
.uleb128 0xb
.uleb128 0x3
.uleb128 0x8
.byte 0x0
.byte 0x0
.byte 0x0
.section .debug_pubnames,"",@progbits
.4byte 0x17
.2byte 0x2
.4byte $Ldebug_info0
.4byte 0x6f
.4byte 0x25
.ascii "main\000"
.4byte 0x0
.section .debug_aranges,"",@progbits
.4byte 0x1c
.2byte 0x2
.4byte $Ldebug_info0
.byte 0x4
.byte 0x0
.2byte 0x0
.2byte 0x0
.4byte $Ltext0
.4byte $Letext0-$Ltext0
.4byte 0x0
.4byte 0x0
.section .debug_str,"MS",@progbits,1
$LASF0:
.ascii "GNU C 4.4.0\000"
$LASF1:
.ascii "test.c\000"
$LASF2:
.ascii "/export/pfs/home/lte_dsp/zhoulibo/test\000"
$LASF3:
.ascii "main\000"
.ident "GCC: (GNU) 4.4.0"
One point to note, I did all this compilation process on a remote machine and
copied all these files to my own PC with QEMU. The path /export/... is a remote
path, but I don't think that's a problem though.
Please let me know if you need more information. I appreciate your help.
Thanks,
Libo Zhou
------------------ Original ------------------
From: "Philippe Mathieu-Daud ";<phi...@redhat.com>;
Send time: Monday, Sep 23, 2019 10:50 PM
To: "Peter Maydell"<peter.mayd...@linaro.org>;
Cc: "Aleksandar Markovic"<aleksandar.m.m...@gmail.com>; "Libo
Zhou"<zhl...@foxmail.com>; "qemu-devel"<qemu-devel@nongnu.org>;
Subject: Re: illegal hardware instruction during MIPS-I ELF linux useremulation
On 9/23/19 4:42 PM, Peter Maydell wrote:
> On Mon, 23 Sep 2019 at 15:40, Philippe Mathieu-Daud <phi...@redhat.com>
> wrote:
>> So currently there is no MIPS-I only CPU.
>> Note that the code got written with MIPS32 in mind, and implementing
>> MIPS-I requires a considerable amount of change in the codebase.
>
> ...but MIPS-I binaries should run on MIPS-II and newer CPUs, shouldn't
> they?
Some MIPS-I instructions where removed for MIPS-II (as RFE) and they are
not implemented. Also some CP0 registers are different.
>> IMO it is likely the RFE (Return from Exception) instruction.
>
> It seems unlikely that a linux userspace binary would be trying to
> execute RFE...
Oh I thought it was system emulation, indeed it can't be RFE.
One GCC release targetting R3000 (Philips PR31700, Toshiba TX39) doesn't
emit NOP for branch's delay slot. I remember QEMU fails to run the
binaries it generates, but I don't remember how it fails.
Libo, can you provide more information about the cross-compiler you use
and the flags you use when calling it please?
Thanks,
Phil.
