blob: a57e2d097e709d4204dede97a08cc43e5cba7b54 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<think>
Okay, so I'm trying to classify this bug report about QEMU as either user-mode or system-mode related. Let me go through the details step by step.
The problem occurs when using QEMU in user mode, specifically with the x86_64 target. The user is running `qemu-x86_64` with the `-g` option to attach a GDB server on port 12345. They're trying to debug `/bin/ls` and encountering issues when calling functions from GDB.
In the first issue, they tried calling `malloc(1)` and got an error about not being able to fetch the "fs_base" register with a remote failure reply 'E14'. Then, after applying a patch that changes how registers are handled in `gdbstub.c`, the function call worked once but failed on subsequent calls. The second attempt gave an error about accessing memory at address 0x40007ffb8f.
They also mentioned modifying `exec.c` to handle page permissions differently, which seems related to allowing writes on a previously read-only page used by GDB for breakpoints on the stack.
From my understanding, QEMU can run in user mode or system mode. User-mode emulation focuses on running individual applications without a full OS, while system mode emulates an entire computer including peripherals and devices.
In this case, since they're using `-L /` which tells QEMU to use the host's root filesystem for the guest process, it seems like they're in user mode because they're executing `/bin/ls` directly under QEMU without a full OS setup. The issues are occurring when trying to debug with GDB and involve register handling and memory permissions specific to the application being debugged.
The error messages and patches point towards problems within the user-mode emulation part of QEMU, specifically how it interacts with the debugger and handles memory for function calls and breakpoints. There's no mention of hardware devices or system-level components which would be more indicative of a system-mode issue.
Therefore, this bug is likely related to user-mode emulation.
</think>
user
|