[PATCH 2/3] bfd/ELF: Retain strong undefined symbols under -z dynamic-undefined-weak
Hakan Candar
hakan@envs.net
Sun Aug 31 10:54:02 GMT 2025
More information about the Binutils mailing list
Sun Aug 31 10:54:02 GMT 2025
- Previous message (by thread): [PATCH 2/3] bfd/ELF: Retain strong undefined symbols under -z dynamic-undefined-weak
- Next message (by thread): [PATCH] Fix symbols truncation for i386pep target
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jan Beulich <jbeulich@suse.com> wrote: >On 16.07.2025 18:03, Hakan Candar wrote: >> Add `bfd_is_undef_symbol` macro for clarity and consistency across >> backends. Adjust symbol hiding and dynamic marking logic in elflink.c >> to treat undefined strong symbols the same as weak ones when applying >> retention rules. >> >> This improves alignment with the gABI and LLD behavior, especially >> under `-z [no]dynamic-undefined-weak`. Backends that already respected >> this logic (e.g., x86_64, ppc) show no regressions, and can now retain >> strong undefined symbols as dynamic relocations via -z dynamic-undefined-weak. > >What does -z dynamic-undefined-weak have to do with strong undefined symbols? >(I guess there is simply some context missing here, but I'd like to understand >that before looking at the patch itself.) > The flag name is admittedly misleading. After I first sent this out as RFC [1], I determined I would reuse the existing dynamic-undefined-weak flag, even though the behavior extends to strong undefined symbols as well. As Fangrui Song pointed out [2], LLD recently generalized the option in exactly this way: it governs retention of both weak and strong undefineds. I mirrored that model for compatibility and to avoid introducing yet another variant flag that controls nearly the same logic. That said, if the consensus is that the current name is too narrow for what it now does, I can rework the patch to split the behavior or introduce a new option. >Jan > >> Some backends that previously did not support `-z [no]dynamic-undefined-weak` >> (e.g., aarch64, mips, riscv) now follow the shared logic correctly as >> described above, enabling dynamic relocations for strong undefineds. >> >> Other backends (e.g., sh4, m68k) do not yet respect the centralized >> behavior and continue to prune undefined symbols unconditionally due >> to backend-specific conditionals. These will be addressed incrementally. Regards, Hakan [1]: https://sourceware.org/pipermail/binutils/2025-July/142081.html [2]: https://sourceware.org/pipermail/binutils/2025-July/142084.html
- Previous message (by thread): [PATCH 2/3] bfd/ELF: Retain strong undefined symbols under -z dynamic-undefined-weak
- Next message (by thread): [PATCH] Fix symbols truncation for i386pep target
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list