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

Thu May 5 10:21:06 PDT 2016

And it landed in r268649.

Peter

On Wed, May 4, 2016 at 9:17 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:

> 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
>

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