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

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.



> Below is my understanding about how glibc is wrong. glibc/elf/dl-tls.c:250 (the `#elif TLS_DTV_AT_TP` part)
> 
>   // I don't know what this piece of code intended to do with non-zero firstbyte...
>   off = roundup (offset, slotinfo[cnt].map->l_tls_align); // roundup(16, 64) = 64
>   if (off - offset < firstbyte) // 64 - 16 ; 32
>     off += slotinfo[cnt].map->l_tls_align;
>   slotinfo[cnt].map->l_tls_offset = off - firstbyte; // 64 - 32 = 32, wrong, should be 64
>   
>   // If firstbyte is 0 (i.e. p_vaddr % l_tls_align == 0), this is simply:
>   off = roundup (offset, slotinfo[cnt].map->l_tls_align);
>   slotinfo[cnt].map->l_tls_offset = off;
>   // and is correct

My understanding of the firstbyte != 0 case is that this is where p_vaddr % p_align is non-zero. Note that if the loader puts the TCB at an address that is 32 modulo p_align then the TLS block of the application in slot 0 will be 64-bit aligned according to its program header. In effect I think glibc is placing the TLS block in a legal position, another legal position would be to place the TCB at an address that was 0 modulo p_align and then place first TLS block at 64 bytes from the start of the TCB. I think we are assuming that glibc should always be doing the latter, but I think the PT_TLS we are giving it is permitting it to do the former. I think this patch would force it to do the latter, and match LLD's calculation. I'm not 100% certain of this at the moment though.


Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D61824