[PATCH] D26033: [ELF] Resolve undefined symbols from archives when linking shared objects

[Eugene Leviant via llvm-commits]

Here is how I stepped on a problem (simplified):

clang a.out.o liba.so libb.so -o executable // got link error here
when used lld, both gold and ld succeeded

liba,so is built this way:

clang a.o libb.so libstatic.a -o liba.so

I wonder is this some sort of malformed or undocumented behavior of ld/gold?

2016-10-27 21:16 GMT+03:00 Rui Ueyama <ruiu at google.com>:
> On Thu, Oct 27, 2016 at 11:08 AM, Rafael Espíndola
> <rafael.espindola at gmail.com> wrote:
>>
>> This is inconsistent with how lld looks at shared libraries.
>>
>> We always use --allow-shlib-undefined, which basically means that we
>> only look at share libraries to see what they provide and trust that
>> they will have all their dependencies at run time.
>>
>> If we absolutely must, we should probably just implement a
>> --no-allow-shlib-undefined. But I would like a very strong
>> justification before we do that.
>
>
> I agreed. We intentionally do not try to resolve symbols in DSOs because it
> doesn't make much sense. Such undefined symbols may be resolved not at
> link-time but at runtime. In scanShlibUndefined, we do not resolves symbols,
> but just mark symbols as ExportDynamic.
>
>>
>>
>> Cheers,
>> Rafael
>>
>> On 27 October 2016 at 11:01, Eugene Leviant <evgeny.leviant at gmail.com>
>> wrote:
>> > evgeny777 created this revision.
>> > evgeny777 added reviewers: ruiu, rafael.
>> > evgeny777 added subscribers: grimar, ikudrin, llvm-commits.
>> > evgeny777 set the repository for this revision to rL LLVM.
>> > evgeny777 added a project: lld.
>> >
>> > When linking DSO lld doesn't resolve symbols from input DSOs in case
>> > those symbols are lazy. Below is an example:
>> >
>> > input.so - has undefined symbol 'print'
>> > libprint.a - defines 'print'
>> >
>> > ld.lld -shared -o output.so input.so libprint.a
>> >
>> > Even though libprint.a has definition of 'print', output.so will have it
>> > undefined.
>> > Later when you link application with output.so, you'll also have to
>> > provide libprint.a
>> >
>> > This patch fixes it.
>> >
>> >
>> > Repository:
>> >   rL LLVM
>> >
>> > https://reviews.llvm.org/D26033
>> >
>> > Files:
>> >   ELF/SymbolTable.cpp
>> >   test/ELF/Inputs/shared4.s
>> >   test/ELF/shared-lazy.s
>> >
>> >
>> > Index: test/ELF/shared-lazy.s
>> > ===================================================================
>> > --- test/ELF/shared-lazy.s
>> > +++ test/ELF/shared-lazy.s
>> > @@ -0,0 +1,10 @@
>> > +# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
>> > +# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux
>> > %p/Inputs/archive.s -o %t2.o
>> > +# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux
>> > %p/Inputs/shared4.s -o %t3.o
>> > +# RUN: llvm-ar rcs %t2.a %t2.o
>> > +# RUN: ld.lld -shared %t3.o -o %t3.so
>> > +# RUN: ld.lld -shared %t.o %t2.a %t3.so -o %t.so
>> > +# RUN: llvm-objdump -t %t.so | FileCheck --check-prefix=DEFINED %s
>> > +
>> > +# DEFINED: _start
>> > +call _entry at plt
>> > Index: test/ELF/Inputs/shared4.s
>> > ===================================================================
>> > --- test/ELF/Inputs/shared4.s
>> > +++ test/ELF/Inputs/shared4.s
>> > @@ -0,0 +1,3 @@
>> > +.globl _shared
>> > +_shared:
>> > +  call _start at plt
>> > Index: ELF/SymbolTable.cpp
>> > ===================================================================
>> > --- ELF/SymbolTable.cpp
>> > +++ ELF/SymbolTable.cpp
>> > @@ -549,9 +549,12 @@
>> >  template <class ELFT> void SymbolTable<ELFT>::scanShlibUndefined() {
>> >    for (SharedFile<ELFT> *File : SharedFiles)
>> >      for (StringRef U : File->getUndefinedSymbols())
>> > -      if (SymbolBody *Sym = find(U))
>> > +      if (SymbolBody *Sym = find(U)) {
>> >          if (Sym->isDefined())
>> >            Sym->symbol()->ExportDynamic = true;
>> > +        else if (Sym->isLazy())
>> > +          addUndefined(U);
>> > +      }
>> >  }
>> >
>> >  // This function processes --export-dynamic-symbol and --dynamic-list.
>> >
>> >
>
>