peripherals: 0.968
architecture: 0.925
user-level: 0.785
graphic: 0.778
debug: 0.735
ppc: 0.719
performance: 0.653
device: 0.609
mistranslation: 0.600
semantic: 0.588
files: 0.533
network: 0.411
kernel: 0.403
permissions: 0.399
PID: 0.386
boot: 0.363
virtual: 0.363
assembly: 0.355
socket: 0.346
risc-v: 0.327
TCG: 0.309
arm: 0.298
x86: 0.292
vnc: 0.290
register: 0.284
VMM: 0.239
hypervisor: 0.217
i386: 0.205
KVM: 0.091

getifaddrs linked with musl libc hangs on big-endian targets
Description of problem:
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;
}
```
Steps to 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 information:
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"