blob: 16ed3bbb8cdd47801a03239435ff1e4b5cca636b (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, I need to classify this bug report as either 'user-mode' or 'system-mode'. Let me read through the problem description again.
The user is running QEMU in a way that involves debugging with GDB. They're using `qemu-x86_64` with options like `-E LD_PROFILE`, which suggests they're profiling the dynamic linker. The command also includes `-g 12345`, indicating they're setting up a remote debugging session on port 12345.
When they start GDB and connect to this QEMU instance, it causes a segfault. They suspect that this is happening because `SIGPROF` signals are being passed to GDB, which isn't handling them correctly. As a workaround, they're ignoring `SIGPROF` in the gdbstub code, but this means they can't catch those signals in GDB anymore.
Now, thinking about QEMU's modes: 'system-mode' refers to when QEMU emulates an entire system with its own kernel and devices. 'User-mode' is for running binaries without a full OS, often used for debugging or testing specific userland applications.
In this case, the problem occurs during a debugging session where they're running `/bin/ls` under QEMU's user-mode emulation (since they specified `-L /`, which sets the root directory). The issue arises with signal handling between GDB and QEMU, specifically around profiling signals (`SIGPROF`). This seems to be an interaction within the userland environment rather than involving system-level components like hardware or a kernel.
So, this bug is related to user-mode because it's about how QEMU handles signals in a debugging context for userland processes. It doesn't involve higher-privilege operations or system devices, which would fall under system-mode.
</think>
user
|