blob: c648ba89d07371bb6c43880510b13ee9605be775 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, I'm trying to figure out whether this bug report is related to user-mode or system-mode in QEMU. Let's break it down.
The issue is that when someone tries to run a chroot into an mips n32 installation using QEMU's user-mode emulator (qemu-mipsn32), they encounter an error loading shared libraries, specifically /lib32/libc.so.6. The error message says it can't read the file data, but all the necessary files and binaries exist with the correct ABI.
From what I know, user-mode emulation in QEMU allows running executables of different architectures without full system virtualization. It's typically used for cross-compiling or testing binaries on a host machine. In user-mode, QEMU runs as an unprivileged process and relies on binfmt_misc to handle foreign binaries by invoking the emulator.
The note mentions that there was an issue with binfmt-misc magic for n32 which needed fixing (issue 843). This suggests that the problem is related to how QEMU's user-mode handles binary formats. Since O32 and N64 work fine, it's likely a specific issue with the N32 ABI handling in the emulator.
The error occurs when trying to load shared libraries, which are crucial for executing dynamically linked programs like bash. If the emulator isn't properly recognizing or loading these libraries, it points towards an issue within user-mode setup rather than system-level virtualization.
Additionally, since the same binaries work on native hardware and the files exist with correct permissions, it's not a file system or permission problem but specifically how QEMU is handling the N32 binaries in user-mode.
Putting this together, I think the bug is related to user-mode because it involves running executables directly without full OS emulation, relying on binfmt_misc, and issues with loading shared libraries which are handled at the process level.
</think>
user
|