[PATCH 1/3] PE-COFF: Fix weak external symbol resolution when strong undef is seen first

Jan Beulich jbeulich@suse.com
Tue Jun 2 05:31:36 GMT 2026


On 30.05.2026 21:15, Peter Damianov wrote:
> When linking PE-COFF objects, a weak external symbol (C_NT_WEAK with an
> aux record specifying a fallback alias) may fail to resolve if a strong
> undefined reference to the same symbol is encountered before the weak
> definition.  This causes "undefined reference" errors for symbols like
> operator new or personality routines that GCC emits as weak externals
> with a fallback to a default implementation.
> 
> There are two problems:
> 
> 1. In coff_link_add_symbols, when the generic linker resolves a weak
>    undefined against an existing strong undefined (NOACT in the action
>    table), the COFF-specific symbol_class and aux record were not stored
>    because the existing hash entry already had non-null class/type from
>    the first (strong) object file.
> 
> 2. In _bfd_coff_generic_relocate_section, the weak alias fallback only
>    triggered for bfd_link_hash_undefweak symbols.  When a strong undef
>    is seen first, the hash type stays bfd_link_hash_undefined (the
>    generic linker does not downgrade it), so the fallback was skipped.

For both of these, where is it written down what the required behavior
is? From your description it sounds as if you're moving from one extreme
("strong" as the overall result) to the other ("weak" as the overall
result), when it kind of feels as if the type of reference may need to
be retained per incoming object file. (Or else "strong" being the
overall result would look to be more likely to be correct.)

Jan


More information about the Binutils mailing list