[PATCH] D53906: [ELF] Allow configuring the TLS layout for an Android executable

[enh via llvm-commits]

On Thu, Nov 1, 2018 at 5:46 PM Ryan Prichard via Phabricator <
reviews at reviews.llvm.org> wrote:

> rprichard added a subscriber: enh.
> rprichard added a comment.
>
> @eugenis @enh
>
> I'm wondering whether moving the `TLS_SLOT_TSAN` slot is feasible. e.g.
> This sanitizer code would stop working, but it could presumably be fixed in
> a newer sanitizer library:
>
>   // The Android Bionic team has allocated a TLS slot for TSan starting
> with N,
>   // given that Android currently doesn't support ELF TLS. It is used to
> store
>   // Sanitizers thread specific data.
>   static const int TLS_SLOT_TSAN = 8;
>
>   ALWAYS_INLINE uptr *get_android_tls_ptr() {
>     return reinterpret_cast<uptr *>(&__get_tls()[TLS_SLOT_TSAN]);
>   }
>
> As to where to move it:
>
> - use initial-exec ELF TLS (but then the sanitizer solib requires a new
> version of Bionic and must not be loaded via dlopen, directly or
> indirectly).
> - use a negative TP offset on arm (and positive on x86).
> - use a mechanism for allocating a slot (something like my
> `pthread_alloc_tls_word_np` proposal for fixing golang on
> http://b/118381796#comment7).
> - change one of the existing slots to a normal pthread field. (e.g.
> `TLS_SLOT_ERRNO` or `TLS_SLOT_DLERROR`)
>

i think the dlerror slot should be completely safe to change... there
shouldn't be any binary compatibility issue there since there's no static
dlerror(3).

(less certain about the errno slot but that _should_ be okay --- `__errno`
is the API that gives you that address.)


> The issue is that our current use of Bionic slots disagrees with the
> standard arm{32,64} ELF TLS ABI. The standard ABI requires negative slots
> on arm and positive on x86. e.g.:
>
> -
> https://github.com/fuchsia-mirror/zircon/blob/0dbac4d37ca09eaebcb5d1337775b9dc78a4ac06/system/public/zircon/tls.h
>
>
> Repository:
>   rLLD LLVM Linker
>
> https://reviews.llvm.org/D53906
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20181101/84f37a1c/attachment.html>