blob: 918755b1bd6aa3ee22fb5c20936865d7bedb0023 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
<think>
Okay, so I need to figure out whether this bug report about the Arm64 binary not running in qemu-arm64 is a user-mode issue or a system-mode issue. Let me start by understanding the problem.
The user provided a binary that runs fine on real aarch64 hardware but doesn't work when run under QEMU's arm64 emulator. It just hangs and uses 100% CPU. They also mentioned compiling OCaml from source, which involved some specific steps including a patch. The test program is a simple "hello, world" that should print and exit.
So the binary works on real hardware but not in QEMU. That suggests something might be wrong with how QEMU emulates the environment. Now, thinking about QEMU's architecture: it has two main modes—user-mode emulation and system-mode emulation. User-mode runs individual programs without a full OS, while system-mode emulates an entire system including peripherals, devices, etc.
In this case, the user is running qemu-arm64 as a userspace emulator. That implies they're using QEMU in user-mode to run the binary directly. If it's not printing anything and looping, maybe there's an issue with how QEMU handles certain instructions or system calls in user-mode for arm64.
Looking deeper into OCaml compilation: the process requires compiling on aarch64 hardware or within a VM that supports aarch64. The provided binary is statically linked, so it should have all necessary dependencies included. If the problem arises only when running under QEMU's user-mode, then it's likely a bug in how QEMU emulates userland processes for arm64.
I don't see any mention of system-level issues like kernel panics or device driver problems, which would point towards system-mode issues. Instead, the focus is on the binary not executing as expected when run directly under QEMU's user-mode emulator. Therefore, this seems to be a problem with user-mode emulation in QEMU.
</think>
user
|