1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, I'm trying to figure out how to classify this bug report for QEMU. The user provided several examples across different architectures—armhf, powerpc64, and sparc64. In each case, they're compiling a simple C program with a cross-compiler and then running it under QEMU.
For armhf, when they run `qemu-arm ./a.out`, it fails because it can't find `/lib/ld-linux-armhf.so.3`. But by specifying the correct ld library and using `--library-path`, it works. So, that's a bit inconsistent but manageable.
Then for powerpc64, running `qemu-ppc64 ./a.out` gives a missing `/lib64/ld64.so.1`. When they try to run it with the ld library specified directly, it results in a segmentation fault with an invalid memory access. But when using `--library-path`, it works.
Similarly, for sparc64, running without specifying ld fails, and even with just the ld path, it segfaults, but adding `--library-path` makes it work.
So, what's happening here? It looks like QEMU isn't correctly handling the dynamic linker (ld) in these cases. The first attempt tries to find the ld in a default location which doesn't exist on the host system. Then, when they manually specify the ld path, it works for some architectures but not others.
The problem seems related to how QEMU is setting up the environment or executing the binary with the correct dynamic linker and library paths. It's not an issue with instructions being faulty or syscalls failing per se, but rather runtime setup—how the process is initialized when running under QEMU.
Therefore, this bug is about runtime errors, specifically in how QEMU handles the execution setup for different architectures, leading to missing ld files or incorrect memory accesses.
</think>
runtime
|