blob: 73a4133d578704478c4ba7b51ba6f64c83adb572 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, let's see. The user is reporting that older programs running under qemu-aarch64 are causing segmentation faults. They provided steps to reproduce using a Debian Jessie or Ubuntu Xenial chroot. The problem started after a specific commit in QEMU. The key point here is that reverting that commit fixes the issue.
The user mentions that the issue is related to old userspace not being prepared for recent CPU features. But they also note that it's strange. The segfaults happen for some programs like ls or bash but not others like dash.
The possible categories are instruction, syscall, or runtime.
Instruction errors usually involve incorrect or unsupported CPU instructions. If QEMU's emulator is generating incorrect instructions for older programs that don't expect new CPU features, that could fit. For example, if the newer QEMU version is using an instruction that older user-space programs aren't compatible with, leading to a segfault.
Syscall errors would relate to system calls being handled incorrectly. However, the user didn't mention anything about syscalls specifically. The problem seems to be more about how the CPU state or instructions are being emulated.
Runtime errors are other issues that occur during execution, not necessarily related to instructions or syscalls. But given that the problem is tied to a specific commit in QEMU's code that affects CPU emulation, it's likely related to instruction handling. The user suspects CPU features, so it's probably an instruction-related issue where QEMU is using a new instruction that older programs can't handle.
Since reverting the commit fixes it, and the commit is in QEMU's aarch64 emulation, it's likely that the commit introduced a new instruction or changed how instructions are handled, causing older programs to crash. So the category should be "instruction".
</think>
instruction
|