blob: 671b7682d7d5ea635d17818dd104220c7c04ba88 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I'm trying to figure out whether this QEMU issue is a user-mode or system-mode problem. Let me break down the information given.
The user reports that when they execute an `icebp` instruction (which is opcode F1), QEMU raises `SIGILL` instead of `SIGTRAP`. On baremetal Linux, it correctly raises `SIGTRAP`, which makes sense because `icebp` generates a debug exception (#DB) without changing the DR6 register.
The user provided steps to reproduce using a simple assembly program that just runs `icebp` and then exits. When run on QEMU, it throws an illegal instruction signal (SIGILL), whereas on actual hardware or baremetal, it's treated as a trap signal (SIGTRAP).
Now, thinking about how QEMU works: in user-mode emulation, QEMU translates guest instructions into host instructions. It handles signals and exceptions by translating them into the appropriate signals for the host environment.
The problem here is that `icebp` is being translated to SIGILL in QEMU but should be SIGTRAP. That suggests an issue with how QEMU's user-mode emulator (qemu-user) is handling this specific instruction.
Since this issue arises when running a program through qemu-user, which emulates the user space of another architecture on the host, it's likely related to user-mode emulation rather than system-mode where QEMU would be emulating an entire OS and hardware setup.
So, because the problem occurs in how signals are being handled for a user-space instruction, this bug is classified under 'user' mode.
</think>
user
|