blob: ad0592e2b25c446e65c45cdf0a52b6a257965522 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
<think>
Okay, so I'm trying to classify this bug report as either user-mode or system-mode related. Let's break down the information provided.
The issue is about QEMU injecting a #UND exception with an incorrect PC value when accessing coprocessor registers in user mode. The user mentioned that usually, accesses to coprocessors require PL1 or higher privileges. However, some can be allowed in user mode (PL0). In this case, the problem occurs only if the register can be accessed from PL0.
The test program they provided shows different outputs on real hardware versus QEMU. On a Pandaboard (real hardware), it prints "Val=0x2 Val2=0x2". But in QEMU, it's "Val=0x1 Val2=0x2". This suggests that the PC value is incorrect when an exception is thrown in user mode.
The key points here are:
1. The problem occurs during user-mode access to coprocessor registers.
2. QEMU handles this by adding an offset of 8 instead of 4, which leads to the wrong PC being reported.
3. This affects the signal handling for SIGILL, which is a user-space issue.
Since the bug is related to how exceptions are handled in user mode and affects program execution within user space, it seems like a user-mode problem. It doesn't involve higher privilege levels beyond what's needed for coprocessor access, nor does it pertain directly to system devices or peripherals.
</think>
user
|