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

Tue May 3 22:03:01 PDT 2016

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160503/1d25c68d/attachment.html>