diff options
Diffstat (limited to 'results/classifier/mode-deepseek-r1:32b/reasoning/user/2604')
| -rw-r--r-- | results/classifier/mode-deepseek-r1:32b/reasoning/user/2604 | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/results/classifier/mode-deepseek-r1:32b/reasoning/user/2604 b/results/classifier/mode-deepseek-r1:32b/reasoning/user/2604 new file mode 100644 index 00000000..dd5fbecc --- /dev/null +++ b/results/classifier/mode-deepseek-r1:32b/reasoning/user/2604 @@ -0,0 +1,15 @@ +<think> +Okay, so I'm trying to figure out whether this QEMU crash is a user-mode or system-mode issue. Let me read through the problem description carefully. + +The user reports that `qemu-arm-static` crashes 100% of the time when running NEON code. They mention that using the same executable in system emulation mode works without issues. The crash happens inside JIT-generated code, and there's no memory access issue like SIGSEGV. + +They provided some GDB output showing a segmentation fault at address `0x409e503c`. Looking at the disassembly around that address, it shows NEON instructions: vld1.8, vst1.8, and some adds and subs. The crash occurs when executing generated NEON code. + +So, QEMU has two main modes: user-mode and system-mode. User-mode is for running binaries directly without a full OS, while system-mode emulates an entire system with hardware devices and so on. + +In this case, the issue happens in user-mode because they're using `qemu-arm-static`, which is part of user-mode emulation. The problem seems to be related to how QEMU handles NEON instructions in JIT-compiled code when running in user mode. Since the same code works in system-mode, it suggests that the problem lies within the user-mode setup and not with the broader system emulation. + +So, I think this is a user-mode issue because it's specifically about executing generated code in that environment. +</think> + +user \ No newline at end of file |