blob: c0416ad1cd529aaacf10577ca2c58aed2f34d1e3 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
<think>
Okay, I need to classify this bug report from QEMU into one of the given categories. Let me start by understanding what's happening here.
The user is reporting an issue where running `ldd /bin/ls` inside a Docker container on an amd64 host with the arm64v8/ubuntu image fails. The error message mentions that the platform doesn't match, and `ldd` exits with code 139.
First, I know that `ldd` is used to display the shared libraries required by a program. In this case, it's failing when run under QEMU's aarch64 emulation. So, something is going wrong in how QEMU handles this process.
Looking at the categories: mistranslation is about incorrect mapping from source to target architecture. Since `ldd` might involve translating system calls and libraries for the emulated architecture, if there's an issue with that translation, it could cause `ldd` to fail.
Other possibilities include device issues, but I don't see any hardware-specific problems mentioned here. It's not related to graphics or networking since those aren't part of this bug. Socket-related issues also don't seem relevant.
The problem occurs in user-mode, as Docker is involved without needing full virtualization. So it's likely within the translation layer rather than the hypervisor or kernel itself.
Performance and permissions are less likely here because the issue isn't about speed or access rights but about functionality failure during runtime.
Considering all this, the most fitting category is 'mistranslation' because `ldd` relies on correctly translating system calls and library lookups between the emulated architecture (aarch64) and the host (amd64). If there's a mistake in how these translations are handled, it would lead to `ldd` failing as described.
</think>
mistranslation
|