1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
<think>
Okay, so I need to figure out whether this bug report is related to user-mode or system-mode issues in QEMU. Let me start by understanding the problem described.
The user is encountering an issue where an ELF loader fails to load a shared object on a ThunderX2 processor running RHEL7. They provided a simple test program, hello.c, which they compile with and without the -armpl flag using the Arm Compiler for HPC 19.3.
When they run the program with the -armpl flag on a machine called Taishan tsv110 (Kunpeng 920), it doesn't work. They get an error message: "qemu:handle_cpu_signal received signal outside vCPU context @ pc=0xffffaaa8844a". However, when they run the same program without the -armpl flag on that machine, it works fine.
On another machine, Taishan 2280 (Cortex-A72), both with and without the -armpl flag work correctly.
They also mentioned using Docker images with CentOS Linux release 7.7.1908, but the behavior remains consistent across that setup as well. The QEMU version is 4.0, specifically qemu-aarch64 version 4.1.91.
Looking at the ldd outputs, when -armpl is used on the problematic machine (Kunpeng 920), it's trying to load several libraries like libamath_generic.so and others. Without -armpl, only a few are loaded. The error occurs specifically when using the -armpl flag on that particular hardware.
Now, thinking about QEMU modes: user-mode emulation runs programs as if they were running natively on the target architecture, but without full OS virtualization. System-mode involves emulating an entire system, including hardware devices and peripherals.
In this case, the problem occurs when running under QEMU's user-mode (since the command is ./qemu/build/aarch64-linux-user/qemu-aarch64 a.out). The error message indicates a CPU signal issue outside vCPU context, which might suggest something wrong with how the ELF file or shared libraries are being loaded in user-mode.
The fact that it works on one machine but not another could be due to differences in CPU architecture support within QEMU's user-mode. Perhaps the Kunpeng 920 has some features or instructions that aren't properly handled when the -armpl flag is used, leading to an issue during the loading of shared objects.
Since the problem occurs specifically in user-mode emulation and relates to the loading of an ELF file and its dependencies, it's likely a bug within QEMU's user-mode handling. It doesn't seem to involve system-level aspects like hardware devices or higher privileges beyond what user-mode requires.
</think>
user
|