From: "Libo Zhou" <zhlb29@foxmail.com>
To: "Philippe Mathieu-Daud" <philmd@redhat.com>,
"Peter Maydell" <peter.maydell@linaro.org>
Cc: qemu-devel <qemu-devel@nongnu.org>,
"Aleksandar Markovic" <aleksandar.m.mail@gmail.com>
Subject: Re: illegal hardware instruction during MIPS-I ELF linux useremulation
Date: Tue, 24 Sep 2019 00:25:57 +0800 [thread overview]
Message-ID: <tencent_28AAA62B694825C348B1DF49@qq.com> (raw)
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 ";<philmd@redhat.com>;
Send time: Monday, Sep 23, 2019 10:50 PM
To: "Peter Maydell"<peter.maydell@linaro.org>;
Cc: "Aleksandar Markovic"<aleksandar.m.mail@gmail.com>; "Libo Zhou"<zhlb29@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 <philmd@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.
next reply other threads:[~2019-09-23 16:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-23 16:25 Libo Zhou [this message]
2019-09-23 16:41 ` illegal hardware instruction during MIPS-I ELF linux useremulation Peter Maydell
2019-09-24 1:05 ` Libo Zhou
2019-09-24 2:32 ` Libo Zhou
2019-09-24 13:31 ` Libo Zhou
2019-09-24 13:42 ` Philippe Mathieu-Daudé
2019-09-24 14:14 ` illegal hardware instruction during MIPS-I ELF linuxuseremulation Libo Zhou
2019-09-24 9:36 ` illegal hardware instruction during MIPS-I ELF linux useremulation Peter Maydell
-- strict thread matches above, loose matches on Subject: below --
2019-09-23 8:15 illegal hardware instruction during MIPS-I ELF linux user emulation Libo Zhou
2019-09-23 12:04 ` Libo Zhou
2019-09-23 12:19 ` illegal " Peter Maydell
2019-09-24 2:10 ` illegal hardware instruction during MIPS-I ELF linux useremulation Libo Zhou
2019-09-24 2:23 ` Libo Zhou
2019-09-23 14:38 ` illegal hardware instruction during MIPS-I ELF linux user emulation Philippe Mathieu-Daudé
2019-09-26 14:31 ` illegal hardware instruction during MIPS-I ELF linux useremulation Libo Zhou
2019-09-26 15:46 ` Philippe Mathieu-Daudé
2019-09-27 8:59 ` Libo Zhou
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=tencent_28AAA62B694825C348B1DF49@qq.com \
--to=zhlb29@foxmail.com \
--cc=aleksandar.m.mail@gmail.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@redhat.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).