blob: 757eded9ff20a45ae0cbfde66f779e5751cb5e3c (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
|
<think>
Okay, let's see. The user provided a bug report about QEMU crashing when running a specific test program. The error message points to the zero_bss function in elfload.c. The problem started after a specific commit in the Linux kernel, and reverting that commit fixes it.
Hmm, the error is in the QEMU user-mode code when loading an ELF file. The zero_bss function is part of the ELF loading process, which initializes the BSS section of the program. The error message says "code should not be reached," which suggests that the program hit an unreachable part of the code, probably due to some unexpected condition.
The user mentioned that this is related to the nolibc-test program from the Linux kernel. The fact that a specific commit introduced the issue implies that the test program's structure or how it's built changed. Since it's under QEMU's user-mode emulation, the problem is likely in how QEMU handles the ELF loading or memory setup for the program.
The categories are instruction, syscall, or runtime. Instruction would be about incorrect CPU instructions. Syscall relates to system calls. Runtime is other runtime errors. Since the error is during ELF loading, specifically in zeroing the BSS section, which is part of the runtime setup before main() is called, this seems like a runtime issue. The problem isn't with a specific syscall or instruction, but with the process of initializing the program's memory sections. So the category should be runtime.
</think>
runtime
|