blob: 7c1100083e4369013506d445f9e3883f9e2b8f4d (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, I'm trying to figure out whether this QEMU bug is user-mode or system-mode related. Let me start by understanding the problem.
The issue occurs when running a program called nolibc-test under qemu-s390x. The error message points to elfload.c line 2239 in zero_bss, saying "code should not be reached." That suggests there's an unexpected path being taken in the code.
Looking at the steps to reproduce: the user built nolibc-test from the Linux kernel tree and ran it under QEMU. The test program crashes with this error. Reverting a specific commit fixes the issue, implying that something changed in that commit caused the problem.
The error is happening in elfload.c, which I know is part of the QEMU user-mode emulation. User-mode deals with executing binaries directly without a full OS, relying on QEMU to handle system calls and emulate the environment. Elfload.c is responsible for loading ELF binaries, so this issue is likely during program initialization or loading.
Since the problem occurs when running an executable under QEMU's user emulator (qemu-s390x), it doesn't involve emulating a full OS or hardware devices beyond what's necessary to run the binary. There's no mention of peripherals or higher privileges, which are more system-mode concerns.
Therefore, this bug is related to user-mode because it's about running a userspace program and issues in how QEMU handles ELF binaries during user emulation.
</think>
user
|