[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20261115065545.1425672-1-yegorslists@googlemail.com>
Date: Sun, 15 Nov 2026 07:55:45 +0100
From: Yegor Yefremov <yegorslists@...glemail.com>
To: musl@...ts.openwall.com
Subject: powerpc64: libc.so fails to link with -mcpu=power10 (pc-relative code)
Hi,
Building musl 1.2.6 for powerpc64le with gcc 15.3.0 and binutils
2.46.1/2.47, with -mcpu=power10 or -mcpu=power11 in CFLAGS, fails
when linking libc.so:
obj/ldso/dlstart.lo: in function `_dlstart':
dlstart.c:(.text+0x24): call to `_dlstart_c' lacks nop, can't restore toc; (toc save/adjust stub)
ld: final link failed: bad value
I reproduced this myself, and the Buildroot autobuilders hit it on
every power10/power11 musl build, e.g.:
https://autobuild.buildroot.org/results/1342da7c9258a93eada96f92f53a643e316ce7f6
My understanding: for POWER10 and later, gcc generates pc-relative
code by default, and such functions are marked as not preserving r2.
The powerpc64 asm assumes TOC-based callees. In crt_arch.h, the
"bl _dlstart_c" / "bl _start_c" has no nop after it. dlsym.s
tail-calls "b __dlsym", and setjmp.s/sigsetjmp.s branch to
__setjmp_toc. So the linker has no way to insert the TOC save/restore
stub. Adding a nop after the bl in crt_arch.h only moves the error to
the __dlsym tail call.
Building musl with -mno-pcrel added to CFLAGS works around it. With
that, libc.so links, and both dynamically and statically linked test
programs built as pc-relative code (setjmp/longjmp, dlopen/dlsym) run
fine under qemu-ppc64le -cpu power10.
Disclosure: I used an AI assistant (Claude) to analyse this failure.
I reproduced the failure and verified the -mno-pcrel workaround
myself, as described above. I'm not submitting a patch.
Regards,
Yegor
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
