[PATCH 2/3] bfd/ELF: Retain strong undefined symbols under -z dynamic-undefined-weak

[Hakan Candar]

On Mon, Sep 1 2025 at 09:07:16 +02:00:00, Jan Beulich 
<jbeulich@suse.com> wrote:
> On 31.08.2025 12:54, Hakan Candar wrote:
>>  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.
> 
> The present name is likely okay to keep (others may want to chime in, 
> though)
> as long as it is made very clear in doc and description that what it 
> does
> goes beyond what its name says. That is, in the doc change imo you 
> don't
> want to simply drop "weak" but emphasize that both weak and "normal"
> ("strong") symbols are dealt with the same way when the option is 
> given.

Noted. I’ll send v2 of the patch series with these improvements.
Thanks for taking the time to review.

> Jan

Regards,
Hakan