blob: 1b651602be745d2f88f2ac676b6a9695beb4f17a (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
id = 2485
title = "getifaddrs linked with musl libc hangs on big-endian targets"
state = "opened"
created_at = "2024-08-06T13:15:52.349Z"
closed_at = "n/a"
labels = ["kind::Feature Request", "linux-user", "workflow::Confirmed"]
url = "https://gitlab.com/qemu-project/qemu/-/issues/2485"
host-os = "Ubuntu"
host-arch = "x86_64"
qemu-version = "qemu-m68k version 8.1.50 (v8.1.0-83-g50e7a40af3-dirty)"
guest-os = "n/a"
guest-arch = "m68k, ppc, ppc64, s390x (likely but untested: or1k, sparc\\*)"
description = """When the following C program (borrowed from curl's `configure`) is compiled for { m68k, ppc, ppc64, s390x } (possibly others, like or1k and sparc) and linked against musl libc, it hangs inside musl when run. Copying the same binaries to real hardware results in success.
```c
#include <stdlib.h>
#include <ifaddrs.h>
int
main (void)
{
struct ifaddrs *ifa = 0;
int error;
error = getifaddrs(&ifa);
if (error || !ifa)
exit(1);
else
exit(0);
return 0;
}
```"""
reproduce = """1. Compile the above program and link it with musl libc (pre-built toolchains are available [here](https://musl.cc/))
2. Run the appropriate `qemu-*` (e.g. `qemu-m68k ./test` or `qemu-ppc ./test`)
3. Observe that the process hangs."""
additional = """This has come up elsewhere:
* https://bugs.gentoo.org/914256
* https://www.openwall.com/lists/musl/2018/05/30/4
* Likely affects or1k but I can't test that at the moment (need to debug an unrelated issue with that toolchain)
* Likely affects sparc but that port/toolchain is also a WIP
Here are some static sample binaries for the above program:
* https://temp.zv.io/qemu-bug.tar.xz (no guarantees of continued existence months or years later)
GitLab labels seem to be missing:
* ~"kind::Bug"
* ~"linux-user"
* ~"target: ppc"
* ~"target: m68k"
* ~"target: s390x""""
|