[PATCH] D61824: [ARM][AArch64] Overalign .tbss (Android Bionic hack) to avoid p_vaddr%p_align!=0

[Ryan Prichard via Phabricator via llvm-commits]

rprichard added a comment.

@nsz @dalias

In D61824#1499997 <https://reviews.llvm.org/D61824#1499997>, @nsz wrote:

> i think glibc is right (comes up with a tlsoffset%p_align == p_vaddr%p_align  for the module) and musl and other implementations are wrong (they may not get the tlsoffset right in this case: it seems musl always computes tlsoffset%p_align==0 on tls variant 1 targets).


Is the (tlsoffset%p_align == p_vaddr%p_align) requirement documented somewhere?

The ELF spec mentions that p_offset and p_vaddr must be congruent w.r.t. both the maximum page size and p_align. For a PT_LOAD segment, it's obvious that page-size congruency is required, because the loader uses mmap for each load segment. The TLS initialization image is copied for each thread, though, so mmap's limitation doesn't apply.

Ulrich Drepper's TLS paper describes the tlsoffset calculation for IA-64 (variant I) without reference to the (p_vaddr % p_align) value:

> tlsoffset_1 = round(16, align_1)
>  tlsoffset_m+1 = round(tlsoffset_m + tlssize_m , align_m+1)

And for IA-32 (variant II):

> To access TLS blocks for modules using the static model the tlsoffset_m offsets
>  have to be known. These values must be subtracted from the thread register value.
>  Unlike what happens on IA-64 where the offsets are added. The offsets are computed
>  as follows:
>  tlsoffset_1 = round(tlssize_1 , align_1)
>  tlsoffset_m+1 = round(tlsoffset_m + tlssize_m+1 , align_m+1)


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D61824