[lld] Reading undefined symbols from dynamic objects

[Nick Kledzik]

Bigger question.  What is the rule for ELF (and PE/COFF) for weak definitions in shared libraries vs object files?

For darwin/mach-o, the linker processes all object files first.  Then it starts looking for unresolved symbols in libraries.  So, any weak-def in a shared library will never override a weak-def in an object file.

But I thought the ELF linker was strictly command line order dependent.  That is, if a shared library is on the command line before an object file, the shared library implementation is used.  In general the resolver is fed atoms in command line order, and the first weak-def wins.   Are you saying that object file weak-defs should always win over shared library weak defs, regardless of command line order?  If so, that sort of comparison should be a resolver option.

-Nick

On Sep 2, 2013, at 2:36 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote:
> Hi all,
> attached is a first try at cleaning up the symbol reading for ELF DSO
> dependencies. Essentially, if a shared library defines a weak symbol,
> it should not be entered into the symbol table. Otherwise another local
> weak definition in the current object will be changed into undef.
> This does not handle the case of a strong symbol in a DSO turning a weak
> definition into undefined, but that seems to be a separate issue.
> 
> Joerg
> <lld.diff>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits