[PATCH] D64930: [ELF][AArch64] Allow PT_LOAD to have overlapping p_offset ranges

Tue Jul 30 08:06:44 PDT 2019

peter.smith added a comment.

In D64930#1605622 <https://reviews.llvm.org/D64930#1605622>, @rprichard wrote:

> I'm not sure about breaking the (p_vaddr % p_align == 0) invariant. ld.bfd, gold, and (for the most part) lld currently provide this invariant for TLS segments in output files.
>
> Supporting n-mod-m alignment isn't free for dynamic TLS -- allocators typically have [posix_]memalign and free APIs, but I'm not aware of APIs that provide n-mod-m alignment. Supporting it may add extra overhead in libc (e.g. in the DTV) to accommodate the misalignment so libc can free the memory later. The n-mod-m property could conceivably leak into an API used for sanitizers (e.g. https://sourceware.org/glibc/wiki/ThreadPropertiesAPI, the proposed __libc_create_dynamic_tls API).
>
> I think there's an interoperability/compatibility issue. Like current Bionic, I don't think the BSDs pay attention to the (p_vaddr % p_align) value, for static or dynamic TLS. glibc uses that value for static TLS segments, but not for dynamic TLS[1]. (i.e. With this change, I believe lld can generate DSOs where some .tbss variables are misaligned when dlopen'ed with glibc.)
>
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=24606

I had a quick look at the PR to see if I could make it fail (with D64930 <https://reviews.llvm.org/D64930> applied) with glibc without hacking the binary with the trim-pt-tls program with this change. I wasn't able to do so although that doesn't mean it is impossible. Having said that I agree that it would be safer to be conservative in our demands on the capabilities of dynamic loaders. As I understand it ld.bfd and ld.gold both set the alignment of the first TLS section to the alignment of PT_TLS (max of any TLS section progbits or nobits).

Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D64930