https://sourceware.org/bugzilla/show_bug.cgi?id=33141
--- Comment #1 from Jens Remus <jremus at linux dot ibm.com> --- I reviewed the bug, the referenced Alpine issue, the referenced fixes, and did some research. My understanding is as follows: Binding defined local symbols in (static) PIE dynamically is not a bug per se. It results in dynamic relocations for those local symbols, which Glibc and musl (at lest for PIE) can apparently resolve. It would be a valid optimization though to bind defined local symbols in (static) PIE locally, which results in `R_*_RELATIVE` relocations, as ELF does not allow for defined local symbol interposition in executables at all (neither PDE nor PIE): > The executable is always the first element of the search list, > so a defined symbol of any binding in the executable cannot be > preempted (interposed). Source: Fangrui Song, ELF interposition and -Bsymbolic, https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic This would result in a more optimal executable, as the defined local symbols are then bound at link-time, so that the loader does not have to the perform the symbol lookup. Additionally this would resolve the issue that musl cannot lacks the capability to resolve dynamic relocations in static PIE. Using the provided references to existing commits I found the following architectures to have "fixed" the issue: - AArch64: ac33b731d214 ("[AArch64] Bind defined symbol locally in PIE") https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=ac33b731d214 - ARM: 1dcb9720d62c ("[ARM] Bind defined symbol locally in PIE") https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=1dcb9720d62c - RISC-V: 39c7793ba8be ("RISC-V: Bind defined symbol locally in PIE") https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=39c7793ba8be - x86: 4e0c91e45402 ("Bind defined symbol locally in PIE") https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=4e0c91e45402 Reviewing the x86 commit 4e0c91e45402 ("Bind defined symbol locally in PIE") I understand the purpose of the following change in elf_x86_64_relocate_section. It prevents a dynamic relocation from being emitted for executables just because option `-Bsymbolic` is not specified, which AFAIK cannot be specified for an executable. The other architecture fixes also have this, but in a slightly diffrerent minimal version, that only replaces the `!SYMBOLIC_BIND (info, h)` with `!(bfd_link_pie (info) || SYMBOLIC_BIND (info, h))`. diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c @@ -4830,8 +4831,8 @@ direct: else if (h != NULL && h->dynindx != -1 && (IS_X86_64_PCREL_TYPE (r_type) - || ! bfd_link_pic (info) - || ! SYMBOLIC_BIND (info, h) + || !(bfd_link_executable (info) + || SYMBOLIC_BIND (info, h)) || ! h->def_regular)) { if ((r_type != R_X86_64_PC64 && r_type != R_X86_64_64) But I have issues to understand the purpose of the following change in elf_x86_64_check_relocs (now scan_relocs). For test purposes I reverted that change on master as well as on 4e0c91e45402 and ran the x86 linker tests (x86-64 cross build on s390x though). None of the tests failed, that could have provided some further insight. None of the other architecture fixes have this. Did they come to the conclusion this change is superfluous? diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c @@ -2073,7 +2073,8 @@ do_size: && (sec->flags & SEC_ALLOC) != 0 && (! IS_X86_64_PCREL_TYPE (r_type) || (h != NULL - && (! SYMBOLIC_BIND (info, h) + && (! (bfd_link_pie (info) + || SYMBOLIC_BIND (info, h)) || h->root.type == bfd_link_hash_defweak || !h->def_regular)))) || (ELIMINATE_COPY_RELOCS As for resolving this PR I have a patch in my pipeline that ports the obvious x86 change to s390, including the tests, and can confirm this relaxes the dynamic relocations for local symbols to `R_390_RELATIVE`. Maybe H.J. Lu can provide more insights on his second change in his patch? I won't attempt a generic fix, for instance changing SYMBOLIC_BIND as suggested to include a test for `!bfd_link_executable (info)`. Please open a separate PR for that. -- You are receiving this mail because: You are on the CC list for the bug.
