[lld] r268178 - ELF: New symbol table design.

Wed May 4 21:17:38 PDT 2016

D19954 should fix this problem.

On Tue, May 3, 2016 at 10:03 PM, Peter Collingbourne <peter at pcc.me.uk>
wrote:

> Thanks Davide, I'll try to take a look tomorrow.
>
> Peter
>
> On Tue, May 3, 2016 at 6:54 PM, Davide Italiano <davide at freebsd.org>
> wrote:
>
>> I'm sorry to bring bad news but this patch breaks (or exposes an
>> existing bug) with --lto-jobs=N, with N > 1.
>> If I try to link llvm-tblgen, I get the following:
>>
>> [...]
>>
>> duplicate symbol:
>> llvm::Twine::toNullTerminatedStringRef(llvm::SmallVectorImpl<char>&)
>> const in lib/libLLVMSupport.a(Twine.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol:
>> llvm::Record::getValueAsListOfStrings(llvm::StringRef) const in
>> lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol: llvm::Record::dump() const in
>> lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol: llvm::DefInit::getAsString() const in
>> lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol: llvm::DefInit::getFieldInit(llvm::Record&,
>> llvm::RecordVal const*, std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&) const in
>> lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol: llvm::IntInit::getAsString() const in
>> lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol:
>> llvm::VarInit::getFieldType(std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > const&) const in
>> lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol:
>> llvm::VarInit::resolveListElementReference(llvm::Record&,
>> llvm::RecordVal const*, unsigned int) const in
>> lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol: llvm::BitRecTy::typeIsConvertibleTo(llvm::RecTy
>> const*) const in lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol: llvm::BitsInit::convertInitializerTo(llvm::RecTy*)
>> const in lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol: llvm::DagRecTy::getAsString() const in
>> lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol: llvm::UnOpInit::resolveReferences(llvm::Record&,
>> llvm::RecordVal const*) const in lib/libLLVMTableGen.a(Record.cpp.o)
>> and LLD-INTERNAL-combined-lto-object
>> duplicate symbol: llvm::BitsRecTy::getAsString() const in
>> lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol:
>> llvm::FieldInit::resolveListElementReference(llvm::Record&,
>> llvm::RecordVal const*, unsigned int) const in
>> lib/libLLVMTableGen.a(Record.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>> duplicate symbol: llvm::SourceMgr::PrintMessage(llvm::SMLoc,
>> llvm::SourceMgr::DiagKind, llvm::Twine const&,
>> llvm::ArrayRef<llvm::SMRange>, llvm::ArrayRef<llvm::SMFixIt>, bool)
>> const in lib/libLLVMSupport.a(SourceMgr.cpp.o) and
>> LLD-INTERNAL-combined-lto-object
>>
>> [...]
>>
>> The cmake invocation looks pretty much like this one:
>>
>> $ cmake -GNinja -DCMAKE_C_COMPILER="/home/davide/llvm/build/bin/clang"
>> -DCMAKE_AR="/home/davide/llvm/build/bin/llvm-ar"
>> -DCMAKE_RANLIB="/usr/bin/true"
>> -DCMAKE_CXX_COMPILER="/home/davide/llvm/build/bin/clang++"
>> -DCMAKE_C_FLAGS="-flto -fuse-ld=lld -Wl,--lto-jobs=4"
>> -DCMAKE_CXX_FLAGS="-flto -fuse-ld=lld -Wl,--lto-jobs=4"
>> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=OFF ../
>>
>> If I revert the patch, llvm-tblgen links successfully.
>>
>> Peter, can you please take a look when you get a chance?
>> As a general consideration, we might want to set up a bot (or enhance
>> existing bots) to test this configuration (e.g. --lto-jobs=2).
>>
>> Thanks!
>>
>>
>> On Mon, May 2, 2016 at 6:45 PM, Rui Ueyama via llvm-commits
>> <llvm-commits at lists.llvm.org> wrote:
>> > I sync'ed to the head today, and I saw the improvement on my machine as
>> > well. This is one of the best patches committed to LLD/ELF. Thank you
>> for
>> > doing this!
>> >
>> > On Mon, May 2, 2016 at 6:41 PM, Peter Collingbourne via llvm-commits
>> > <llvm-commits at lists.llvm.org> wrote:
>> >>
>> >> http://reviews.llvm.org/D19836 is the fix for Rafael's reproducer. Ed,
>> >> please let me know if it fixes the issue for you.
>> >>
>> >> Peter
>> >>
>> >> On Mon, May 2, 2016 at 1:02 PM, Peter Collingbourne <peter at pcc.me.uk>
>> >> wrote:
>> >>>
>> >>> On Mon, May 2, 2016 at 12:55 PM, Rafael Espíndola
>> >>> <rafael.espindola at gmail.com> wrote:
>> >>>>
>> >>>> To reproduce the problem:
>> >>>>
>> >>>> clang -c test.s
>> >>>> clang -c test2.s
>> >>>> llvm-ar rc test2.a test2.o
>> >>>> ld.lld -shared -o test.so  test2.a test.o
>> >>>>
>> >>>> with
>> >>>>
>> >>>> test.s:
>> >>>>         addq    a at GOTTPOFF(%rip), %rax
>> >>>> test2.s:
>> >>>>         .section        .tdata,"awT", at progbits
>> >>>>         .globl  a
>> >>>> a:
>> >>>>         .long   42
>> >>>
>> >>>
>> >>> Was able to reproduce, looking.
>> >>>
>> >>> Thanks,
>> >>> --
>> >>> --
>> >>> Peter
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> --
>> >> Peter
>> >>
>> >> _______________________________________________
>> >> llvm-commits mailing list
>> >> llvm-commits at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>> >>
>> >
>> >
>> > _______________________________________________
>> > llvm-commits mailing list
>> > llvm-commits at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>> >
>>
>> --
>> Davide
>>
>> "There are no solved problems; there are only problems that are more
>> or less solved" -- Henri Poincare
>>
>
>
>
> --
> --
> Peter
>

-- 
-- 
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160504/f09e61c0/attachment.html>