1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Okay, so I'm trying to classify this bug report about QEMU and ARM emulation. The user provided some code that interacts with the FPSCR register in ARM. They say that when they run it on a real ARM machine, the output is "000000000000000000000000fff7009f", but when they run it under QEMU, they get "000000000000000000000000ffffffff".
Looking at the code, they're loading a value into r0 from i0, then writing that to FPSCR using vmsr. Then they read back the FPSCR into r4 and store it in o. The output shows differences in the bits after the first 12 bytes. So, QEMU is allowing some reserved bits in FPSCR to be set when it shouldn't.
The user mentions that according to the ARM manual, certain bits (like bits [19], [14:13], and [6:5]) should remain zero as they are RES0 (reserved and must read as 0). But QEMU isn't enforcing this; these bits can be modified.
Now, looking at the possible categories: instruction, syscall, runtime. The issue seems to be with how QEMU handles the FPSCR register's write operations. It's not correctly maintaining certain bits as zero when they should be. This is related to how the emulator executes instructions involving that register.
So, this isn't a problem with a specific instruction or a system call. Instead, it's an issue during runtime where the state of a register isn't being managed correctly according to architecture specifications.
</think>
runtime
|