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

[Ryan Prichard via Phabricator via llvm-commits]

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`)

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