blob: 12f0913d5d6203492340bb9e3cd74f3f9ca32806 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
|
<think>
Alright, I need to classify this bug report under one of the given categories: instruction, syscall, or runtime. Let's break it down step by step.
The user is reporting an issue where QEMU-user doesn't report HWCAP2_MTE. They provided a specific commit hash and host details. The test case with mte-3.c works correctly, printing "OK", but their custom test mytest.c fails, outputting 0 instead of the expected value.
Looking at the code in mytest.c, it's checking for HWCAP2_MTE using getauxval(AT_HWCAP2). It seems that QEMU isn't setting this bit when it should. The problem occurs during runtime because the program is executing and making a system call (getauxval) which returns incorrect information.
The issue arises when running under QEMU with --cpu max, suggesting it's not correctly emulating or reporting CPU capabilities. This affects how the program runs, specifically in detecting MTE support via HWCAP2.
So, this isn't an instruction fault or a syscall error per se, but rather an incorrect runtime behavior where QEMU doesn't report the correct HWCAP2 flags. Therefore, it's classified under 'runtime'.
</think>
runtime
|