blob: 1488d7472cfbc984eea10ac19d072658c29bb35f (
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 for QEMU. The user has provided some information about regressions they noticed when running GCC tests on an arm926 target using a specific configuration. Let me break down what's given and figure out which category it fits into.
First, the context: They're using QEMU master after a particular commit. They applied a fix for bug 1834496 but still saw regressions when running GCC tests. The GCC is configured to generate arm10tdmi code with VFP support, and they're testing against the --cpu arm926 option in QEMU.
The issue arises during runtime because they're executing the test binaries on QEMU and observing failures. The problem isn't in a specific instruction that's incorrect but rather in how the CPU is handling the generated code from GCC.
Looking at the possible categories:
- **instruction**: This would apply if there was a specific instruction causing issues, like an assembly-level bug. But here, it's more about overall execution behavior.
- **syscall**: If the problem were related to system calls not being handled correctly, this category would fit. However, the user didn't mention any syscall errors.
- **runtime**: This seems appropriate because the regressions are happening when running the tests on QEMU, implying issues during execution rather than compile-time or instruction-level problems.
So, putting it all together, the bug is related to runtime behavior when executing GCC-generated code on arm926 with VFP. The issue isn't a specific syscall failure but how the CPU is processing the instructions at runtime.
</think>
runtime
|