| 2018-06-03 00:06:11 |
Haskell Pointer |
description |
Greetings,
I've been using qemu-system-aarch64 to do some low-level programming targeting the raspberry pi 3. While I was debugging a problem in my code I noticed a very confusing inconsistency that I think is very likely a bug somewhere in how qemu's monitor produces it's disassembled output.
Here's my version output (installed via homebrew on macOS 10.13.4)
$ qemu-system-aarch64 --version
QEMU emulator version 2.12.0
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
Some system information (macOS 10.13.4):
$ uname -a
Darwin Lillith.local 17.5.0 Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64 x86_64
Here's an example of the problem I am seeing:
qemu-system-aarch64 -S -M raspi3 -kernel kernel8.img -monitor stdio
QEMU 2.12.0 monitor - type 'help' for more information
(qemu) x /32x 0x80000
0000000000080000: 0xd53800a1 0x92400421 0xb4000061 0xd503205f
0000000000080010: 0x17ffffff 0x58000161 0x9100003f 0x58000161
0000000000080020: 0x180000e2 0x34000082 0xf800843f 0x51000442
0000000000080030: 0x35ffffa2 0xd2806763 0x17ffffff 0x00000000
0000000000080040: 0x00080000 0x00000000 0x00080050 0x00000000
0000000000080050: 0x00000000 0x00000000 0x00000000 0x00000000
0000000000080060: 0x00000000 0x00000000 0x00000000 0x00000000
0000000000080070: 0x00000000 0x00000000 0x00000000 0x00000000
(qemu) x /32i 0x80000
0x00080000: d53800a1 mrs x1, mpidr_el1
0x00080004: 92400421 and x1, x1, #3
0x00080008: b4000061 cbz x1, #0x80014
0x0008000c: d503205f wfe
0x00080010: 17ffffff b #0x8000c
0x00080014: 58000161 ldr x1, #0x80040
0x00080018: 9100003f mov sp, x1
0x0008001c: 58000161 ldr x1, #0x80048
0x00080020: 92400421 and x1, x1, #3
0x00080024: b4000061 cbz x1, #0x80030
0x00080028: d503205f wfe
0x0008002c: 17ffffff b #0x80028
0x00080030: 58000161 ldr x1, #0x8005c
0x00080034: 9100003f mov sp, x1
0x00080038: 58000161 ldr x1, #0x80064
0x0008003c: 180000e2 ldr w2, #0x80058
0x00080040: 34000082 cbz w2, #0x80050
0x00080044: f800843f str xzr, [x1], #8
0x00080048: 51000442 sub w2, w2, #1
0x0008004c: 35ffffa2 cbnz w2, #0x80040
0x00080050: d2806763 movz x3, #0x33b
0x00080054: 17ffffff b #0x80050
0x00080058: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x0008005c: 00080000 .byte 0x00, 0x00, 0x08, 0x00
0x00080060: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x00080064: 00080050 .byte 0x50, 0x00, 0x08, 0x00
0x00080068: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x0008006c: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x00080070: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x00080074: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x00080078: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x0008007c: 00000000 .byte 0x00, 0x00, 0x00, 0x00
Please notice that between 0x80004 thru 0x8001c is repeated for some reason in the /32i formatted output which also causes the addresses for the following bytes to also be incorrect.
Just in order to keep things as clear as possible, I'll also attach the binary shown above but disassembled by objdump instead of qemu.
$ aarch64-elf-objdump -d kernel8.elf
kernel8.elf: file format elf64-littleaarch64
Disassembly of section .text:
0000000000080000 <_start>:
80000: d53800a1 mrs x1, mpidr_el1
80004: 92400421 and x1, x1, #0x3
80008: b4000061 cbz x1, 80014 <_start+0x14>
8000c: d503205f wfe
80010: 17ffffff b 8000c <_start+0xc>
80014: 58000161 ldr x1, 80040 <_start+0x40>
80018: 9100003f mov sp, x1
8001c: 58000161 ldr x1, 80048 <_start+0x48>
80020: 180000e2 ldr w2, 8003c <_start+0x3c>
80024: 34000082 cbz w2, 80034 <_start+0x34>
80028: f800843f str xzr, [x1], #8
8002c: 51000442 sub w2, w2, #0x1
80030: 35ffffa2 cbnz w2, 80024 <_start+0x24>
80034: d2806763 mov x3, #0x33b // #827
80038: 17ffffff b 80034 <_start+0x34>
8003c: 00000000 .word 0x00000000
80040: 00080000 .word 0x00080000
80044: 00000000 .word 0x00000000
80048: 00080050 .word 0x00080050
8004c: 00000000 .word 0x00000000
Hopefully this is helpful information, please let me know if I left out anything really important. Thank you! |
Greetings,
I've been using qemu-system-aarch64 to do some low-level programming targeting the raspberry pi 3. While I was debugging a problem in my code I noticed a very confusing inconsistency that I think is very likely a bug somewhere in how qemu's monitor produces its disassembled output.
Here's my version output (installed via homebrew on macOS 10.13.4)
$ qemu-system-aarch64 --version
QEMU emulator version 2.12.0
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
Some system information (macOS 10.13.4):
$ uname -a
Darwin Lillith.local 17.5.0 Darwin Kernel Version 17.5.0: Fri Apr 13 19:32:32 PDT 2018; root:xnu-4570.51.2~1/RELEASE_X86_64 x86_64
Here's an example of the problem I am seeing:
qemu-system-aarch64 -S -M raspi3 -kernel kernel8.img -monitor stdio
QEMU 2.12.0 monitor - type 'help' for more information
(qemu) x /32x 0x80000
0000000000080000: 0xd53800a1 0x92400421 0xb4000061 0xd503205f
0000000000080010: 0x17ffffff 0x58000161 0x9100003f 0x58000161
0000000000080020: 0x180000e2 0x34000082 0xf800843f 0x51000442
0000000000080030: 0x35ffffa2 0xd2806763 0x17ffffff 0x00000000
0000000000080040: 0x00080000 0x00000000 0x00080050 0x00000000
0000000000080050: 0x00000000 0x00000000 0x00000000 0x00000000
0000000000080060: 0x00000000 0x00000000 0x00000000 0x00000000
0000000000080070: 0x00000000 0x00000000 0x00000000 0x00000000
(qemu) x /32i 0x80000
0x00080000: d53800a1 mrs x1, mpidr_el1
0x00080004: 92400421 and x1, x1, #3
0x00080008: b4000061 cbz x1, #0x80014
0x0008000c: d503205f wfe
0x00080010: 17ffffff b #0x8000c
0x00080014: 58000161 ldr x1, #0x80040
0x00080018: 9100003f mov sp, x1
0x0008001c: 58000161 ldr x1, #0x80048
0x00080020: 92400421 and x1, x1, #3
0x00080024: b4000061 cbz x1, #0x80030
0x00080028: d503205f wfe
0x0008002c: 17ffffff b #0x80028
0x00080030: 58000161 ldr x1, #0x8005c
0x00080034: 9100003f mov sp, x1
0x00080038: 58000161 ldr x1, #0x80064
0x0008003c: 180000e2 ldr w2, #0x80058
0x00080040: 34000082 cbz w2, #0x80050
0x00080044: f800843f str xzr, [x1], #8
0x00080048: 51000442 sub w2, w2, #1
0x0008004c: 35ffffa2 cbnz w2, #0x80040
0x00080050: d2806763 movz x3, #0x33b
0x00080054: 17ffffff b #0x80050
0x00080058: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x0008005c: 00080000 .byte 0x00, 0x00, 0x08, 0x00
0x00080060: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x00080064: 00080050 .byte 0x50, 0x00, 0x08, 0x00
0x00080068: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x0008006c: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x00080070: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x00080074: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x00080078: 00000000 .byte 0x00, 0x00, 0x00, 0x00
0x0008007c: 00000000 .byte 0x00, 0x00, 0x00, 0x00
Please notice that between 0x80004 thru 0x8001c is repeated for some reason in the /32i formatted output which also causes the addresses for the following bytes to also be incorrect.
Just in order to keep things as clear as possible, I'll also attach the binary shown above but disassembled by objdump instead of qemu.
$ aarch64-elf-objdump -d kernel8.elf
kernel8.elf: file format elf64-littleaarch64
Disassembly of section .text:
0000000000080000 <_start>:
80000: d53800a1 mrs x1, mpidr_el1
80004: 92400421 and x1, x1, #0x3
80008: b4000061 cbz x1, 80014 <_start+0x14>
8000c: d503205f wfe
80010: 17ffffff b 8000c <_start+0xc>
80014: 58000161 ldr x1, 80040 <_start+0x40>
80018: 9100003f mov sp, x1
8001c: 58000161 ldr x1, 80048 <_start+0x48>
80020: 180000e2 ldr w2, 8003c <_start+0x3c>
80024: 34000082 cbz w2, 80034 <_start+0x34>
80028: f800843f str xzr, [x1], #8
8002c: 51000442 sub w2, w2, #0x1
80030: 35ffffa2 cbnz w2, 80024 <_start+0x24>
80034: d2806763 mov x3, #0x33b // #827
80038: 17ffffff b 80034 <_start+0x34>
8003c: 00000000 .word 0x00000000
80040: 00080000 .word 0x00080000
80044: 00000000 .word 0x00000000
80048: 00080050 .word 0x00080050
8004c: 00000000 .word 0x00000000
Hopefully this is helpful information, please let me know if I left out anything really important. Thank you! |
|
