Lines Matching refs:is
12 ELF TLS is a system for automatically allocating thread-local variables with cooperation among the
21 At run-time, TLS variables are allocated on a module-by-module basis, where a module is a shared
40 an executable, the linker needs to know where an executable's TLS segment is relative to the TP so
42 thread-specific data layout, but variant 1 is more problematic than variant 2.
46 1, and its storage will always be immediately after (or before) the TP. In variant 1, the TP is
48 from TP is implementation-defined.
50 The DTV's "generation" field is used to lazily update/reallocate the DTV when new modules are loaded
100 `R_TLS_DTPMOD` is a dynamic relocation to the index of the module containing `tls_var`, and
101 `R_TLS_DTPOFF` is a dynamic relocation to the offset of `tls_var` within its module's `PT_TLS`
105 the module's TLS block. Before it can do this, it ensures that the module's TLS block is allocated.
106 A simple approach is to allocate memory lazily:
108 1. If the current thread's DTV generation count is less than the current global TLS generation, then
111 2. If the DTV's entry for the given module is `NULL`, then `__tls_get_addr` allocates the module's
121 LD is a specialization of GD that's useful when a function has references to two or more TLS
158 If the variable is part of the Static TLS Block (i.e. the executable or an initially-loaded shared
159 object), then its offset from the TP is known at load-time. The variable can be accessed with a few
175 // Unlike DTPOFF, which is relative to the start of the module’s block,
176 // TPOFF is directly relative to the thread pointer.
186 LE is a specialization of IE. If the variable is not just part of the Static TLS Block, but is also
192 // R_TLS_TPOFF() is resolved at (static) link-time
214 use it, which can break `dlopen` if the surplus area is exhausted. See:
225 As long as a shared object is one of the initially-loaded modules, a better option is to use
233 LD models, there is a newer, more efficient design that uses "TLS descriptors". Each TLS variable
322 The traditional TLS design is implemented everywhere, but the TLSDESC design has less toolchain
329 * Gold and LLD support for TLSDESC is spotty (except when targeting arm64).
335 object file compiled with `-fpic` is linked into an executable, the linker could relax GD accesses
376 library is typically a shared object, but for Android, we link our own `libthread_db.a` into
390 anything: the `GetThreadPointer` function is no longer implemented. Code for reading the thread
406 > question therefore is the exact field layouts required. Happily, the implementors of libpthread
424 The debugger lookup process is straightforward:
457 The dynamic initialization and destruction of C++ `thread_local` variables is layered on top of ELF
461 Aside: Because a `__thread` variable cannot have dynamic initialization, `__thread` is more
472 Static executables aren't a problem--the necessary runtime support is part of the executable, so TLS
478 * On arm64, the primary TLS relocation (R_AARCH64_TLSDESC) is [confused with an obsolete
479 R_AARCH64_TLS_DTPREL32 relocation][R_AARCH64_TLS_DTPREL32] and is [quietly ignored].
494 There is an [ELF TLS prototype] uploaded on Gerrit. It implements:
544 The prototype's `__tls_get_addr` might be async-signal safe. Making it AS-safe is a good idea if
545 it's feasible. musl's function is AS-safe, but glibc's isn't (or wasn't). Google had a patch to make
562 On the other hand, maybe lazy allocation is a feature, because not all threads will use a dlopen'ed
565 > In addition the run-time support should avoid creating the thread-local storage if it is not
568 > lazy method is wanted. This is not much extra burden since the requirement to handle dynamically
569 > loaded objects already requires recognizing storage which is not yet allocated. This is the only
592 The `bionic_tls.h` header is marked with a warning:
597 ** This header file is *NOT* part of the public Bionic ABI/API
601 ** It is only provided here for the benefit of the system dynamic
609 * `TLS_SLOT_STACK_GUARD` is used for `-fstack-protector`. The location (word #5) was initially used
610 by GCC on x86 (and x86-64), where it is compatible with x86's TLS variant 2. We [modified Clang
615 * `TLS_SLOT_TSAN` is used for more than just TSAN -- it's also used by [HWASAN and
619 searching for its TP-relative offset, which it assumes is nonnegative:
640 example, it could be used to load an arm32 solib into an x86 Zygote.) The solib is translated
645 * A `pthread_t` is practically just a `pthread_internal_t*`, and some apps directly access the
650 slots into a new data structure. Variant 1 is a harder problem.
680 * When linking an executable, the static linker needs to know how TLS is allocated because it
756 * 16 isn't enough for the pthread keys, so the Go runtime is still a problem.
757 * Reserving 138 words is enough for existing slots and pthread keys.
762 * memory layout is the same on all architectures, avoids native bridge complications
766 * The reserved amount is still arbitrary.
780 The layout conflict is apparently only a problem because an executable assumes that its TLS segment
781 is located at a statically-known offset from the TP (i.e. it uses the LE model). An initially-loaded
782 shared object can still use the efficient IE access model, but its TLS segment offset is known at
790 A likely problem: LD is normally relaxed to LE, not to IE. We'd either have to disable LD usage in
816 it is typically zero. After [Bionic's pthread key system was rewritten to be
846 the loader is allocating it.