[PATCH] D12226: [LLD] Support for --unresolved-symbols option in llvm lld for ELF file format

[shridHar joshi via llvm-commits]

On Thu, Sep 3, 2015 at 8:44 PM, Joerg Sonnenberger via llvm-commits <
llvm-commits at lists.llvm.org> wrote:


> I think I agree with Joerg. When we are just using a DSO, it doesn't make
> sense to warn on undefined symbols in the DSO.

> Your test case looks like it's testing against that
> case. libfoo_unresolved-symbols.so has undefined symbols in it, and the
> test is testing if LLD print error messages on it when linking against
> libfoo_unresolved-symbols.so.

Let us take a use case below:
$cat main.c
#include <stdio.h>
extern int var;
int main() {
   printf("main: %d\n",var);
   return 0;
}

$cat foo.c
int var = 10;
extern int bar();
int foo() {
   bar();
   return 0;
}


$gcc -shared -fpic foo.c -o libfoo.so
$gcc main.c -L. -lfoo
./libfoo.so: undefined reference to `bar'
collect2: error: ld returned 1 exit status


In above example because of data variable var, libfoo.so is in DT_NEEDED
list and so gnu linker (as well as gold linker) is reporting error
(default) for undefined reference bar() called from foo() even if foo() is
not being referenced.

in case of gnu ld and gold, allow shlib undefined is false (default) while
creating executable and true while creating shared library (-shared option).

For same test case lld does not report any error.
This is because lld implementation has default allow shlib undefined true.

is this defect in lld? or lld is designed with this awareness?

While creating executable, if the library is not in the DT_NEEDED list then
lld should not report undefined reference from that library, even with any
option. I will fix this with --unresolved-symbols option implementation.
(Will fix the test case as well).

But above mentioned different behavior of lld compared to gnu ld and gold
is critical to resolve.

This information clarity is important for implementation of -Bgroup,
-static, -z now, --[warn|error]-unresolved-symbols options.

http://reviews.llvm.org/D12226#238177

-Shridhar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150914/59e34886/attachment.html>