summaryrefslogtreecommitdiffstats
path: root/results/classifier/gemma3:12b/debug/1774830
diff options
context:
space:
mode:
authorChristian Krinitsin <mail@krinitsin.com>2025-07-03 07:27:52 +0000
committerChristian Krinitsin <mail@krinitsin.com>2025-07-03 07:27:52 +0000
commitd0c85e36e4de67af628d54e9ab577cc3fad7796a (patch)
treef8f784b0f04343b90516a338d6df81df3a85dfa2 /results/classifier/gemma3:12b/debug/1774830
parent7f4364274750eb8cb39a3e7493132fca1c01232e (diff)
downloademulator-bug-study-d0c85e36e4de67af628d54e9ab577cc3fad7796a.tar.gz
emulator-bug-study-d0c85e36e4de67af628d54e9ab577cc3fad7796a.zip
add deepseek and gemma results
Diffstat (limited to 'results/classifier/gemma3:12b/debug/1774830')
-rw-r--r--results/classifier/gemma3:12b/debug/177483099
1 files changed, 99 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/debug/1774830 b/results/classifier/gemma3:12b/debug/1774830
new file mode 100644
index 00000000..78f7ffc0
--- /dev/null
+++ b/results/classifier/gemma3:12b/debug/1774830
@@ -0,0 +1,99 @@
+
+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! \ No newline at end of file