getifaddrs linked with musl libc hangs on big-endian targets
Host environment
- Operating system: Ubuntu
- OS/kernel version:
Linux 6.7.0 #1 SMP PREEMPT_DYNAMIC Mon Jan 22 07:51:29 CST 2024 x86_64 x86_64 x86_64 GNU/Linux - Architecture: x86_64
- QEMU flavor:
qemu-m68k(likely big-endian targets) - QEMU version:
qemu-m68k version 8.1.50 (v8.1.0-83-g50e7a40af3-dirty) - QEMU command line: n/a (qemu-user)
Emulated/Virtualized environment
- Operating system: n/a
- OS/kernel version: n/a (see above)
- Architecture: m68k, ppc, ppc64, s390x (likely but untested: or1k, sparc*)
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.
#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
- Compile the above program and link it with musl libc (pre-built toolchains are available here)
- Run the appropriate
qemu-*(e.g.qemu-m68k ./testorqemu-ppc ./test) - 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:
Edited by Zach van Rijn