1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, so I'm trying to figure out how to classify this bug report about QEMU's user-mode emulation. The problem is that when running certain programs, like gcc on Alpine Linux AArch64, there's a segfault because the ELF interpreter is being mapped at address 0 in the guest space. This causes issues with musl libc which interprets a NULL base address incorrectly.
Looking at the description, it seems the issue arises during the loading of the ELF image where the load_addr is set to 0 for the interpreter. Then, when this is passed to target_mmap(), QEMU translates this guest address into a host address. Since guest_base isn't zero, it's trying to map the interpreter at actual address 0 on the host, which violates Linux's policy of not mapping anything there.
The user provided a patch that modifies the mmap functions in QEMU's linux-user/mmap.c. They changed how want_p is calculated by checking if start is non-zero before translating it. So, when start is zero (NULL), they pass 0 to mmap instead of translating it via g2h_untagged.
Now, thinking about the categories: instruction, syscall, runtime. This issue doesn't seem to be directly related to an incorrect instruction being executed or a problem with a specific system call itself. Instead, it's more about how memory is being managed and mapped during runtime, leading to unexpected behavior when the program runs.
So, I think this falls under "runtime" because it's an error that occurs while the program is executing, specifically due to incorrect address mapping.
</think>
runtime
|