1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
<think>
Okay, so I have this problem where QEMU 1.4.1 is behaving inconsistently across different architectures when running a simple Hello World program. Let me try to understand what's going on here.
First, looking at the armhf case: The user compiled a hello.c program using arm-linux-gnueabihf-gcc and then tried to run it with qemu-arm. Initially, they got an error about missing /lib/ld-linux-armhf.so.3. Then, by explicitly providing the ld-2.17.so from the arm-linux-gnueabihf directory, they still had issues because libc.so.6 wasn't found. But when they added --library-path to include that directory, it worked.
Now, for powerpc64: They compiled with powerpc64-linux-gcc and tried running with qemu-ppc64. The first run failed because /lib64/ld64.so.1 was missing. Then, trying to specify the ld-2.17.so from the powerpc64-linux/lib64 directory resulted in a segmentation fault with some error messages about memory access and registers.
Similarly, for sparc64: The initial run failed because /lib64/ld-linux.so.2 was missing. When they tried to specify the ld-2.17.so manually, it caused a segmentation fault, but adding --library-path made it work.
So, the pattern here is that on armhf and sparc64, specifying the library path after the dynamic linker works, but on powerpc64, even when doing that, it crashes with a segmentation fault. That's inconsistent behavior across architectures.
Now, I need to classify this bug report into either 'user-mode' or 'system-mode'. User-mode issues are related to how QEMU handles user-space programs and their execution without involving the full OS. System-mode involves more of the system, like devices, peripherals, higher privileges, etc.
In these cases, the problem seems to be with how QEMU is handling the dynamic linker and library paths when executing a program in user mode. The fact that some architectures work after specifying the correct paths but others don't suggests it's an issue within the user-mode emulation of QEMU for those specific architectures.
Therefore, this bug report is likely related to 'user-mode'.
</think>
The inconsistency arises from how QEMU handles dynamic linking and library paths in different architectures during user-space program execution. The errors point to issues with loading libraries correctly without system-level involvement, indicating a user-mode problem.
user
|