diff options
Diffstat (limited to 'results/classifier/105/device/1774830')
| -rw-r--r-- | results/classifier/105/device/1774830 | 118 |
1 files changed, 118 insertions, 0 deletions
diff --git a/results/classifier/105/device/1774830 b/results/classifier/105/device/1774830 new file mode 100644 index 000000000..c9425394e --- /dev/null +++ b/results/classifier/105/device/1774830 @@ -0,0 +1,118 @@ +device: 0.683 +other: 0.680 +boot: 0.610 +instruction: 0.599 +KVM: 0.583 +semantic: 0.568 +vnc: 0.532 +mistranslation: 0.531 +assembly: 0.503 +socket: 0.479 +graphic: 0.470 +network: 0.428 + +qemu monitor disassembled memory dump produces incorrect output + +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! + + + +I think this is likely a duplicate of bug https://bugs.launchpad.net/qemu/+bug/1900779 which has recently been fixed. Could you please check with the latest release candidate of QEMU 5.2 whether the issue is fixed for you? Thanks! + +Looking at your patch and the fix in commit 437588d81d99ac91cb1e, the modifications are the same, so this issue should be fixed, indeed. Big sorry that your bug report here fell through the cracks, but at least it's fixed now. Closing this ticket as duplicate. + |