[EXT] Re: [lld] r355894 - Fix test to unconditionally create a GNU-format archive.

[Rui Ueyama via llvm-commits]

On Wed, Mar 13, 2019 at 5:30 PM Eli Friedman <efriedma at quicinc.com> wrote:

> I spent a bit of time looking at this.  By default, llvm-ar will
> automatically generate a symbol table… which suppresses the lld error
> because lld never looks at unneeded object files in an archive with a
> symbol table.  However, there’s an exception: if the host is not Darwin,
> and the archive contains no object files, llvm-ar skips generating a symbol
> table even if one is requested.
>
>
>
> Maybe it makes sense to change the behavior of llvm-ar so it’s more
> consistent… I’m not sure what the history is behind making the symbol table
> behavior depend on the archive format.
>
>
>
> On a sort of related note, maybe we want to change lld so it doesn’t
> generate the “not an ELF file” error for archives which don’t have a symbol
> table?  That would be more consistent with the behavior of archives with a
> symbol table.
>

We have an interesting (or ugly?) hack for an archive file containing no
symbol table.

If we see an archive file containing no symbol table, it is likely that a
user is attempting LTO and using system's ar instead of llvm-ar. Since the
system's ar doesn't understand the LLVM bitcode, it cannot create a symbol
table, thus such an archive. This is very common error, it seems that
virtually everybody once hit when doing LTO for the first time, so we have
a workaround in lld that it automatically pulls out files from such an
archive and link them according to the archive file semantics.

(Maybe we should check if all member files in an archive file with no
symbol table are bitcode files, though.)


>
> -Eli
>
>
>
> *From:* Rui Ueyama <ruiu at google.com>
> *Sent:* Wednesday, March 13, 2019 4:23 PM
> *To:* Eli Friedman <efriedma at quicinc.com>
> *Cc:* llvm-commits <llvm-commits at lists.llvm.org>
> *Subject:* [EXT] Re: [lld] r355894 - Fix test to unconditionally create a
> GNU-format archive.
>
>
>
> lld uses LLVM's libObject to read archive files, and I believe the library
> supports all variants of archive files, so it is odd that lld can't read
> some archive variant. Something is not right...
>
>
>
> On Mon, Mar 11, 2019 at 7:18 PM Eli Friedman via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
> Author: efriedma
> Date: Mon Mar 11 19:20:01 2019
> New Revision: 355894
>
> URL: http://llvm.org/viewvc/llvm-project?rev=355894&view=rev
> Log:
> Fix test to unconditionally create a GNU-format archive.
>
> On Darwin targets, llvm-ar creates a Darwin format archive by default,
> which ld.lld can't read, so it was printing an unexpected error.
>
>
> Modified:
>     lld/trunk/test/ELF/invalid/invalid-elf.test
>
> Modified: lld/trunk/test/ELF/invalid/invalid-elf.test
> URL:
> http://llvm.org/viewvc/llvm-project/lld/trunk/test/ELF/invalid/invalid-elf.test?rev=355894&r1=355893&r2=355894&view=diff
>
> ==============================================================================
> --- lld/trunk/test/ELF/invalid/invalid-elf.test (original)
> +++ lld/trunk/test/ELF/invalid/invalid-elf.test Mon Mar 11 19:20:01 2019
> @@ -2,7 +2,7 @@
>  # RUN: rm -rf %t && mkdir -p %t
>  # RUN: llvm-mc %s -o %t/simple.o -filetype=obj -triple x86_64-pc-linux
>  # RUN: echo > %t/empty.o
> -# RUN: llvm-ar cr %t/not-elf.a %t/empty.o
> +# RUN: llvm-ar --format=gnu cr %t/not-elf.a %t/empty.o
>
>  # RUN: not ld.lld %t/simple.o %t/not-elf.a -o %t2 2>&1 | \
>  # RUN:   FileCheck --check-prefix=NOT-ELF %s
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190314/1d09b879/attachment.html>