[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
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&#x27;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


More information about the Binutils mailing list