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

shridHar joshi via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 2 02:14:46 PDT 2015


>It's better to define enums for these strings and use them in Resolver.cpp
instead of strings.
Yes, enum will be good

>I'm wondering if this is correct. Does --unresolved-symbols really negate
--allow-shlib-undefines?
Not all values of --unresolved-symbols option negate
--allow-shlib-undefines.
But --allow-shlib-undefines option is only for shared libraries
whereas --unresolved-symbols is for relocatable object files, shared
libraries as well as executable.
I have tested behavior of all values of  --unresolved-symbols in
combination with --allow-shlib-undefines and --no-allow-shlib-undefines
with gnu ld and gold.

Implementation of --unresolved-symbols option submitted in lld is in
compliance with gnu ld and gold.

@Simon Atanasyan,

>Is it possible to escape using Clang in the test? Usually build-bots do
not build Clang with LLD
Sure, I will update test case by avoiding clang usage.


On Wed, Sep 2, 2015 at 12:44 PM, Rui Ueyama <ruiu at google.com> wrote:

> ruiu added a subscriber: ruiu.
>
> ================
> Comment at: lib/Driver/GnuLdDriver.cpp:439-442
> @@ +438,6 @@
> +    }
> +    else if (val.compare("ignore-all") &&
> +             val.compare("report-all") &&
> +             val.compare("ignore-in-object-files") &&
> +             val.compare("ignore-in-shared-libs")) {
> +
> ----------------
> It's better to define enums for these strings and use them in Resolver.cpp
> instead of strings.
>
> ================
> Comment at: lib/Driver/GnuLdDriver.cpp:458
> @@ +457,3 @@
> +    ctx->setPrintRemainingUndefines(true);
> +    ctx->setAllowRemainingUndefines(false);
> +  }
> ----------------
> I'm wondering if this is correct. Does --unresolved-symbols really negate
> --allow-shlib-undefines?
>
>
> http://reviews.llvm.org/D12226
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150902/8420f1ea/attachment.html>


More information about the llvm-commits mailing list