[llvm-bugs] [Bug 37841] New: Missing SHF_TLS section error with ELF TLS and --pack-dyn-relocs=android

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=37841

            Bug ID: 37841
           Summary: Missing SHF_TLS section error with ELF TLS and
                    --pack-dyn-relocs=android
           Product: lld
           Version: unspecified
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: rprichard at google.com
                CC: llvm-bugs at lists.llvm.org

lld prints a missing SHF_TLS section error given the combination of arm64, a
static ELF TLS variable, and Android-style packed relocations. Test case:

    static __thread char tlsvar;
    char bump() {
      return ++tlsvar;
    }

$ /x/clang6/bin/clang test.c -nostdlib -shared -fpic -target
aarch64-linux-android -fuse-ld=lld -Wl,--pack-dyn-relocs=android
-fno-emulated-tls

Output:

/x/clang6/bin/ld.lld: error: /tmp/test-bca6ac.o has an STT_TLS symbol but
doesn't have an SHF_TLS section
clang-6.0: error: linker command failed with exit code 1 (use -v to see
invocation)

There is an SHF_TLS section in the object file. It links fine if I omit
-Wl,--pack-dyn-relocs=android, and it also works on other architectures (e.g.
arm-linux-androideabi).

I think the problem is that the Android relocation packing code is using the
global Out::TlsPhdr variable before it's been initialized. The Android packing
code (updateAllocSize/encodeDynamicReloc) needs to get the addend of a TLS
relocation, and for that, it calls getSymVA on a TLS symbol, which reads the
global Out::TlsPhdr pointer. Out::TlsPhdr isn't initialized until setPhdrs is
called, though, and the packing code is called from finalizeSections.

Backtrace from the error:

#0  getSymVA (Sym=..., Addend=@0x7fffffffbcd0: 0) at
/x/llvm-upstream/llvm/tools/lld/ELF/Symbols.cpp:94
#1  0x00007ffff6c74c70 in lld::elf::Symbol::getVA (this=0x65d630, Addend=0) at
/x/llvm-upstream/llvm/tools/lld/ELF/Symbols.cpp:111
#2  0x00007ffff6c7a8ff in lld::elf::DynamicReloc::computeAddend (this=0x680a50)
at /x/llvm-upstream/llvm/tools/lld/ELF/SyntheticSections.cpp:1399
#3  0x00007ffff6c7fa50 in
encodeDynamicReloc<llvm::object::ELFType<(llvm::support::endianness)1, true> >
(P=0x7fffffffbef0, Rel=...) at
/x/llvm-upstream/llvm/tools/lld/ELF/SyntheticSections.cpp:1455
#4  0x00007ffff6ca6660 in
lld::elf::AndroidPackedRelocationSection<llvm::object::ELFType<(llvm::support::endianness)1,
true> >::updateAllocSize (this=0x6670d0)
    at /x/llvm-upstream/llvm/tools/lld/ELF/SyntheticSections.cpp:1564
#5  0x00007ffff6d37429 in (anonymous
namespace)::Writer<llvm::object::ELFType<(llvm::support::endianness)1, true>
>::finalizeSections (this=0x7fffffffc728)
    at /x/llvm-upstream/llvm/tools/lld/ELF/Writer.cpp:1697
#6  0x00007ffff6d128eb in (anonymous
namespace)::Writer<llvm::object::ELFType<(llvm::support::endianness)1, true>
>::run (this=0x7fffffffc728) at
/x/llvm-upstream/llvm/tools/lld/ELF/Writer.cpp:447
#7  0x00007ffff6d4ba5a in
lld::elf::writeResult<llvm::object::ELFType<(llvm::support::endianness)1, true>
> () at /x/llvm-upstream/llvm/tools/lld/ELF/Writer.cpp:145
#8  0x00007ffff6af7f7d in
lld::elf::LinkerDriver::link<llvm::object::ELFType<(llvm::support::endianness)1,
true> > (this=0x647bc0, Args=...) at
/x/llvm-upstream/llvm/tools/lld/ELF/Driver.cpp:1383
#9  0x00007ffff6adfed8 in lld::elf::LinkerDriver::main (this=0x647bc0,
ArgsArr=...) at /x/llvm-upstream/llvm/tools/lld/ELF/Driver.cpp:402
#10 0x00007ffff6adf6ab in lld::elf::link (Args=..., CanExitEarly=true,
Error=...) at /x/llvm-upstream/llvm/tools/lld/ELF/Driver.cpp:98
#11 0x0000000000401946 in main (Argc=16, Argv=0x7fffffffd688) at
/x/llvm-upstream/llvm/tools/lld/tools/lld/lld.cpp:132

Backtrace from Out::TlsPhdr initialization (w/o packed relocations):

#0  (anonymous
namespace)::Writer<llvm::object::ELFType<(llvm::support::endianness)1, true>
>::setPhdrs (this=0x7fffffffc758) at
/x/llvm-upstream/llvm/tools/lld/ELF/Writer.cpp:2087
#1  0x00007ffff6d129e6 in (anonymous
namespace)::Writer<llvm::object::ELFType<(llvm::support::endianness)1, true>
>::run (this=0x7fffffffc758) at
/x/llvm-upstream/llvm/tools/lld/ELF/Writer.cpp:471
#2  0x00007ffff6d4ba5a in
lld::elf::writeResult<llvm::object::ELFType<(llvm::support::endianness)1, true>
> () at /x/llvm-upstream/llvm/tools/lld/ELF/Writer.cpp:145
#3  0x00007ffff6af7f7d in
lld::elf::LinkerDriver::link<llvm::object::ELFType<(llvm::support::endianness)1,
true> > (this=0x647bb0, Args=...) at
/x/llvm-upstream/llvm/tools/lld/ELF/Driver.cpp:1383
#4  0x00007ffff6adfed8 in lld::elf::LinkerDriver::main (this=0x647bb0,
ArgsArr=...) at /x/llvm-upstream/llvm/tools/lld/ELF/Driver.cpp:402
#5  0x00007ffff6adf6ab in lld::elf::link (Args=..., CanExitEarly=true,
Error=...) at /x/llvm-upstream/llvm/tools/lld/ELF/Driver.cpp:98
#6  0x0000000000401946 in main (Argc=15, Argv=0x7fffffffd6b8) at
/x/llvm-upstream/llvm/tools/lld/tools/lld/lld.cpp:132

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180619/ace7bc3f/attachment-0001.html>