1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I need to figure out whether this bug report is about user-mode or system-mode in QEMU. Let's break it down.
The user is reporting regressions when running GCC tests on the arm-linux-gnueabihf target with some GCC tests. They're using a specific configuration for GCC: --target arm-none-linux-gnueabihf, which suggests they're cross-compiling for an ARM target that doesn't have a full Linux system, maybe something like bare-metal or a minimal environment.
They mention running the GCC testsuite and seeing QEMU crash with recent versions. The fact that these were passing before but now fail indicates a regression in QEMU's handling of this scenario.
Looking at how QEMU works, user-mode (also known as qemu-user) is used for cross-compiling and testing binaries on different architectures without running a full OS. It emulates the CPU and runs the binary directly, which is exactly what GCC tests would be doing when checking cross-compiled programs.
System-mode, on the other hand, involves running a full virtual machine with an operating system, handling peripherals, devices, etc. Since the user isn't mentioning anything about running an OS or dealing with device emulations, it's more likely related to user-mode.
The bug report also includes binaries and shared libraries, which are typical when testing cross-compiled programs in user-mode without a full OS context. The script they're using probably just runs these binaries under QEMU-user, not a full VM setup.
So putting it all together, the issue is with how QEMU handles these specific ARM binaries in user-mode emulation, causing crashes where there weren't any before.
</think>
user
|