blob: 6c43d08c05ed7f2b80912ce670fa1b797b1f7d25 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I have this bug report about QEMU having an ARM CPU emulation regression when using the .NET Core SDK 3.1 on Debian 10 armhf. The user is saying that when they try to build their C# projects with dotnet build or test, MSBuild crashes with a SEHException. That usually means there's some issue where managed code is trying to call into unmanaged code incorrectly.
They tested this using QEMU versions 4.2.0 and 5.0.0, both of which show the problem. However, older versions like 4.1.0 and 4.1.1 don't have this issue. They also confirmed that a real Raspberry Pi 2 works fine with the same setup.
Looking at the environment details, they're running QEMU on an AMD Ryzen host, usingvirtio devices for storage and networking. The guest is Debian 10 armhf with kernel 4.19. So it's definitely about how QEMU emulates the ARM CPU in these newer versions.
Now, I need to classify this bug as either user-mode or system-mode related. System-mode issues typically involve higher-level privileges, devices, peripherals, and the OS itself. User-mode issues are more about applications running on top of the OS.
Since the crash is happening within MSBuild, which is a user-space application trying to JIT compile code, it seems like an issue with how the CPU emulation interacts with the .NET runtime. The problem arises when MSBuild attempts to execute native binaries from managed code, leading to an SEHException. This suggests that there's something wrong in how QEMU handles ARM instructions or memory management for user-space processes.
Given that the crash is within a user-space application and not related to device drivers or kernel operations, this likely falls under a user-mode issue. It's about how the emulator handles regular application execution rather than system-level components.
</think>
user
|