[llvm-dev] Weak undefined symbols and dynamic libraries

[Rui Ueyama via llvm-dev]

On Fri, Oct 13, 2017 at 11:27 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:

> 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:
>

We have -shared/-pie options, so my intention was to use these flags. We
could use relocations to make a decision whether we should export an weak
undefined symbols or not, but I think there are a few issues with that:

1. We cannot make a decision until we visit all relocations, but we need a
decision beforehand in order to create GOT entries or report errors.

2. Sometimes we could get mixed signals -- for example, if some object file
contains a direct reference to a weak symbol, and other object file
contains a GOTPCREL reference to the same symbol, they are somewhat
conflicting.

So, just using -pie/-shared flags is simple, I guess?

-----------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171015/1648d473/attachment.html>