blob: 4c5a545971bf8d05a7b15777659984eb74d03b6c (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I need to figure out whether this bug report is user-mode related or system-mode related in QEMU. Let me start by understanding the problem.
The issue revolves around a discrepancy in how the initial program break (brk) is calculated for a statically-linked binary when run under QEMU user-mode versus Linux. The brk value set by QEMU is lower than expected, causing a crash on the second brk call, while it works fine on real ARM hardware.
Looking at the program headers provided, there are several LOAD segments with different properties. The key seems to be how each system determines where to set the initial brk. In Linux's binfmt_elf.c, the brk is set after all loadable segments, regardless of their flags. However, in QEMU user-mode, it seems that info->brk is only incremented for LOAD segments with PROT_WRITE permissions.
The problematic segment in question has both read and write permissions (RW) and overlaps with a TLS segment which is read-only. The brk set by Linux is higher than the one in QEMU because Linux doesn't consider whether the segment is writable when determining the initial break point, whereas QEMU does.
Since this issue pertains to how QEMU's user-mode emulator calculates the program break based on ELF headers and memory segments, it falls under user-mode emulation. The problem isn't related to system hardware or higher-privilege operations but rather how user-space programs are loaded and their memory is managed in the emulator.
Therefore, the bug report is about user-mode functionality within QEMU.
</think>
user
|