[RFC] Standardizing undefined symbol relocation retention in ELF ld.bfd

[Hakan Candar]

Hi Jan,

Thanks a lot for the detailed response and clarification. The point about 
focusing on the current master branch makes perfect sense, and I appreciate 
the feedback on the table and scope as well.

A couple of follow-up notes:

- It's possible that my result for aarch64 on 2.43 was incorrect or due to 
  a misconfigured local setup. I can’t verify this at the moment since I 
  don’t have access to my development machine, but I’ll recheck as soon as 
  I return. It may be good for the maintainers to double-check as well in 
  case my observation was off.

- For riscv64, I had already tested with 2.44 and master, and it behaves 
  correctly. The table mistakenly implied that only 2.44 was fixed - that 
  was a wording oversight.

- For m68k, my test was limited to binutils 2.40. I’ll rerun it on master 
  when I’m back and include the result in the updated table.

I'm currently away on vacation until July 7, but I’ll revisit everything 
with tests against current master once I return. I’ll send an updated 
summary table with only up-to-date behavior and begin preparing follow-up 
patches from there.

Thanks again for your time, and for cc’ing the relevant maintainers.

Best regards,
Hakan Candar


On 02/07/2025 10:59, Jan Beulich <jbeulich@suse.com> wrote:

>  On 01.07.2025 22:52, Hakan Candar wrote:
>  > I've been working with ELF dynamic symbol resolution in ld.bfd and came
>  > across some surprising inconsistencies when it comes to how undefined
>  > symbols - both weak and strong - are handled across different backends
>  > and versions.
>  >
>  > Currently, the behavior of undefined symbol retention varies not only
>  > across architectures, but even across different binutils versions of the
>  > same architecture. This leads to situations where the same source and
>  > linker flags behave differently depending on target and toolchain
>  > version, making it difficult for users to write portable and predictable
>  > link lines.
>  >
>  > Here's a summary of the behavior I observed:
>  > (Strong symbols were tested with --unresolved-symbols=ignore-all)
>  
>  As a general comment - for what actions to take, the state of the present
>  master branch is what matters. Older versions' behaviors are of only
>  academic interest from that perspective. Hence the (perhaps nit-picky)
>  comments on some of the table entries below.
>  
>  > Target     | Version | Keeps Weak | Keeps Strong | Accepts -z dynamic-undefined-weak
>  > -----------+---------+------------+--------------+----------------------------------
>  > x86-64     | 2.41+   | Yes        | No*          | Yes
>  > aarch64    | 2.41    | Yes        | No           | No (warns)
>  > aarch64    | 2.43    | Yes        | Yes          | No (warns)
>  > aarch64    | 2.45    | Yes        | No           | No (warns)
>  
>  I.e. there's a regression here? Unless this was a deliberate move back to
>  earlier behavior, I think this would better be taken care of before 2.45
>  goes out. Cc-ing Nick and the Arm64 maintainers.
>  
>  > riscv64    | 2.41    | Broken**   | Broken**     | No (warns)
>  > riscv64    | 2.44    | Yes        | Yes          | No (warns)
>  
>  I expect you mean 2.44+ here, following the spelling used for other
>  targets? Or is there yet something else wrong in current master?
>  
>  > ppc64le    | 2.41+   | Yes        | Yes          | Yes
>  > m68k       | 2.40    | No***      | No***        | No (warns)
>  
>  And again presumably 2.40+?
>  
>  > *: Unresolved strong symbol can be retained with --export-dynamic, but not -fPIE -pie.
>  >
>  > **: The linker retained unresolved symbol relocations as dynamic relocations, correctly
>  >     emitted .got/.got.plt entries and the @plt thunk; however, the function call
>  >     erroneously jumped to address 0 instead of the expected func@plt stub.
>  >
>  > ***: Unresolved strong symbol can be retained with -fPIE -pie, but with --export-dynamic.
>  >
>  > To the best of my knowledge, the behavior described above reflects the
>  > state of each backend as tested or inspected in the relevant binutils
>  > versions. However, due to the evolving nature of these implementations,
>  > some edge cases or version-specific nuances may differ slightly. I'm
>  > happy to be corrected on any of these observations if needed.
>  >
>  > The flag `-z dynamic-undefined-weak` is supported only by a few
>  > backends (e.g., x86-64, ppc64), while others warn or ignore it. Even
>  > without the flag, some backends retain weak and/or strong undefined
>  > symbols by default, leading to divergence in behavior.
>  >
>  > This inconsistency makes it difficult to reason about dynamic linking,
>  > runtime symbol resolution (e.g., via LD_PRELOAD), or symbol stubbing
>  > scenarios, especially across targets.
>  >
>  > **Proposal**
>  >
>  > I would like to propose centralizing the undefined symbol retention
>  > policy for ELF targets inside `elflink.c`, and treating flags like
>  > `-z dynamic-undefined-weak` (and a potential new flag `-z
>  > dynamic-undefined` for strong symbols) in a uniform, target-agnostic
>  > way.
>  
>  Absolutely. Target specific code should come into play here only if a
>  psABI deliberately overrides gABI.
>  
>  > This would involve:
>  >   - Moving the decision logic for retaining undefined symbols to shared
>  >     code (e.g., elflink.c)
>  >   - Respecting per-backend defaults via a new backend flag
>  >   - Honoring user-specified flags to override the default (without
>  >     warnings)
>  >   - Adding test coverage for undefined weak/strong symbol handling on
>  >     multiple targets
>  >   - Avoiding behavior regressions by preserving current behavior unless
>  >     the user opts in
>  
>  I'm not sure about this one - anything violating involved gABI rules
>  (hopefully they don't leave room for interpretation) would better be
>  fixed as default behavior, if necessary providing options to revert to
>  prior (bogus) behavior.
>  
>  Jan
>