[PATCH] D61824: [ARM][AArch64] Overalign SHF_TLS instead of PT_TLS (Android Bionic hack) to make glibc happy

[Szabolcs Nagy via Phabricator via llvm-commits]

nsz added a comment.

In D61824#1502690 <https://reviews.llvm.org/D61824#1502690>, @rprichard wrote:

> I think that basically works. It would add a TLS segment to every Android executable, even those that aren't using ELF TLS:
>
> - If the placeholder symbol has size 1 and 64-byte alignment, then every Android executable (targeting Q(29) and up) would have a PT_TLS segment of 64-byte size and alignment with gold or lld.
> - If the placeholder symbol in .tdata has size 0 instead, then ld.bfd omits the .tdata section from the output if there aren't any other non-empty .tdata sections. This is a problem if there are other TLS sections (.tbss). Android is switching to lld, though, so maybe it's OK. (The NDK still defaults to bfd and gold.)
> - If the placeholder symbol has a size of 48 bytes and 1-byte alignment, then libc.so can't use alignment to detect whether space was reserved. I can think of a couple ways for space to not be reserved:
>   - Using an NDK that's too old
>   - Using a too-old NDK API level, assuming this placeholder symbol is omitted when targeting old versions of Bionic (because Q(29) is currently rejecting an underaligned TLS segment...)


i think the placeholder tls symbol size and alignment should
be exactly such that it covers the bionic internal tls slots.

if the symbol has default visibility then the libc can check
at runtime that it really covers the required range.

if the symbol is missing from an executable then it is only
safe to load if there is no static tls in it. the libc can
take care of static tls in other modules (their static tls
offset is decided by the libc)

in principle the symbol check can be done using weak reference
but i don't think undef weak tls sym reliably evaluates to 0,
so i'd just rely on plain symbol interposition (placeholder
is size 1 extern tls sym in libc that is interposed by the
placeholder from the .exe)

> Aside: An `R_{ARM,AARCH64}_NONE` relocation to a TLS symbol has the desired effect. Is there a better way to create this relocation than by using a hex editor?

why not export the symbol?
then it cannot be removed for sure.
(i think gas has a .reloc directive that accepts R_AARCH64_NONE as argument, not sure if llvm handles that)


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61824/new/

https://reviews.llvm.org/D61824