blob: 6c7a55fa2c1989e15ea7f5062f66ff851f603dba (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I'm looking at this bug report for QEMU involving the Cortex-M55 CPU. The user is running into an assertion failure when they try to execute a dummy test program. Let me break down what's happening here.
First, the command used is `qemu-arm -cpu cortex-m55 dummy_test`. This suggests that they're using QEMU in user mode because the `-cpu` option typically specifies the CPU type for user-mode emulation. User mode in QEMU allows running standalone applications without a full OS, which aligns with their setup of a simple test program.
The error message mentions `page_set_flags: Assertion 'last <= GUEST_ADDR_MAX' failed`. This points to an issue within the TCG (Translation-CPU) component of QEMU. The TCG is responsible for translating guest code into host code during emulation, which happens in both user and system modes. However, since they're not running a full OS here, it's more likely a user-mode issue.
Looking at their steps: they compiled a dummy test with `arm-none-eabi-gcc` targeting Cortex-M55 and then ran it under QEMU. The compiler seems up-to-date, so the problem isn't likely on the host side but rather in how QEMU handles the Cortex-M55 in user mode.
The linked issue on GitLab also mentions a similar problem with Cortex-M CPUs, which further supports that this is related to user-mode emulation since they're testing without an OS. System-mode issues usually involve more complex setups like device emulation or peripheral interactions, which aren't mentioned here.
Therefore, considering the use of `qemu-arm` and the absence of system-level components in their test, this bug is likely a 'user' mode issue.
</think>
The issue occurs when running user-mode QEMU with the Cortex-M55 CPU, indicating it's related to user-mode emulation.
user
|