blob: 3e698a4abe86c59c9ca37f094e6103126fe84dbc (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
<think>
Okay, I need to figure out whether this bug is user-mode related or system-mode related. Let me start by understanding the problem.
The issue is about an ELF binary crashing in user-mode emulation but running fine in system-mode (QEMU full-system). The crash happens during thread-local storage initialization because the AT_PHDR value from the aux vector is incorrect in user-mode.
Looking at the provided information:
- In the kernel's view, AT_PHDR is 0x900000.
- In QEMU's user-mode, it's 0xae000. This discrepancy causes the crash.
The user mentions that they built a custom kernel to debug and see the aux vector. The problem arises when using qemu-arm in user-mode with GDB, which shows a different AT_PHDR value than what the kernel provides.
I know that QEMU has two modes: system-mode (emulating an entire OS) and user-mode (just running binaries without full OS). In system-mode, the kernel is involved, so the aux vector is set by the kernel. In user-mode, QEMU acts as a standalone emulator and sets up the aux vector itself.
The fact that AT_PHDR differs between kernel and user-mode suggests an issue in how QEMU's user-mode calculates or retrieves the program headers. This is likely a bug within QEMU's user-mode emulation of the ELF loading process, possibly not correctly mapping the segments as the kernel does.
Since the problem occurs only in user-mode and involves aux vector setup during binary execution without full OS context, it points to a user-mode issue.
</think>
The problem arises from QEMU's user-mode incorrectly setting the AT_PHDR value, causing a mismatch compared to the kernel. This is specific to how user-mode emulates the ELF loading process.
user
|