[llvm-dev] Weak undefined symbols and dynamic libraries

[Rafael Avila de Espindola via llvm-dev]

Rui Ueyama <ruiu at google.com> writes:

> I think the current behavior is bad. I'd like to propose the following
> changes:
>
> 1. If a linker is creating a non-PIC ELF binary, and if it finds a DSO
> symbol foo for an undefined weak symbol foo, then it adds foo as a *strong*
> undefined symbol to the dynamic symbol table. This prevents the above crash
> because the program fails to start if foo is not found at load-time,
> instead of crashing at run-time.
>
> 2. If a linker is creating a non-PIC ELF binary, and if it *cannot* find a
> DSO symbol foo for an undefined weak symbol foo, then it *does not* add foo to
> the dynamic symbol table, and it sets foo's value to zero.

I would not phrase this as pic/non-pic. From the linker point of view
there are just relocations. I assume then that the intention is:

-----------------------------------------------------------------
Sometimes a linker has to create a symbol in the main binary so that it
is preempted from a shared library at runtime. That symbol is then used
with a copy relocation if it is an object or a special plt entry if it
is a function.

If the symbol in question was a weak undefined:

* If the symbol was found in a .so the resulting undefined reference
  will be strong.
* If the symbol was not found in a .so, it is resolved to 0 and there is
  no undefined reference.

If no relocation requires the symbol to be preempted to the main
executable (all relocations use a got for example) then there will still
be an weak undefined reference since the dynamic linker will be able to
handle the symbol existing or not.
-----------------------------------------------------------------

I agree that that is probably a good change.

Cheers,
Rafael