Lines Matching refs:to
25 few instructions. TLS variables belonging to dlopen'ed shared objects, on the other hand, may be
38 According to Drepper, variant 2 was motivated by backwards compatibility, and variant 1 was designed
40 an executable, the linker needs to know where an executable's TLS segment is relative to the TP so
44 Each thread has a "Dynamic Thread Vector" (DTV) with a pointer to each module's TLS block (or NULL
47 expected to point immediately at the DTV pointer, whereas in variant 2, the DTV pointer's offset
50 The DTV's "generation" field is used to lazily update/reallocate the DTV when new modules are loaded
57 When a C/C++ file references a TLS variable, the toolchain generates instructions to find its
70 A GD access can refer to a TLS variable anywhere. To access a variable `tls_var` using the
72 call to a `__tls_get_addr` function provided by libc.
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`
104 `__tls_get_addr` looks up `TlsIndex::module_id`'s entry in the DTV and adds `TlsIndex::offset` to
106 A simple approach is to allocate memory lazily:
121 LD is a specialization of GD that's useful when a function has references to two or more TLS
122 variables that are both part of the same module as the reference. Instead of a call to
123 `__tls_get_addr` for each variable, the compiler calls `__tls_get_addr` once to get the current
124 module's TLS block, then adds each variable's DTPOFF to the result.
171 Compiles to:
175 // Unlike DTPOFF, which is relative to the start of the module’s block,
176 // TPOFF is directly relative to the thread pointer.
188 IE example compiles to:
225 As long as a shared object is one of the initially-loaded modules, a better option is to use
235 to pass to the resolver.
261 The dynamic loader fills in the TLS descriptors. For a reference to a variable allocated in the
289 need to use an atomic or synchronized access of the global TLS generation counter.
317 The loader needs to allocate a table of `TlsDescDynamicArg` objects for each TLS module with dynamic
320 The static linker can still relax a TLSDESC-based access to an IE/LE access.
328 * GCC and Clang default to TLSDESC on arm64 and the traditional design on other architectures.
334 than the compiler, so it can "relax" TLS accesses to more efficient models. For example, if an
336 to IE or LE. To relax a TLS access, the linker looks for an expected sequences of instructions and
337 static relocations, then replaces the sequence with a different one of equal size. It may need to
375 gdb uses a libthread_db plugin library to retrieve thread-related information from a target. This
377 gdbserver. We will need to implement at least 2 APIs in `libthread_db.a` to find TLS variables, and
380 * Reference: [gdb_proc_service.h]: APIs gdb provides to libthread_db
401 Both debuggers need metadata from the threading library (`libc.so` / `libpthread.so`) to find TLS
405 > Drepper's TLS ELF ABI document, so we can easily write code to decode it ourselves. The only
416 `_thread_db_pthread_dtvp` | Offset from TP to DTV pointer (0 for variant 1, implementation-…
418 `_thread_db_dtv_t_pointer_val` | Offset within a DTV slot to the pointer to the allocated TLS bl…
426 * Use `_thread_db_link_map_l_tls_modid` to find the TLS variable's module ID.
428 * Use `_thread_db_pthread_dtvp` to find the thread's DTV.
429 * Use `_thread_db_dtv_dtv` and `_thread_db_dtv_t_pointer_val` to find the desired module's block
431 * Add the module-relative offset to the module pointer.
434 read past the end of an out-of-date DTV or access an unloaded module. To be robust, it needs to
445 * x86_64: use `PTRACE_PEEKUSER` to read the `{fs,gs}_base` fields of `user_regs_struct`
464 each access, to call a function to initialize the variable.
484 to these executables that only newer platforms recognize? (e.g. maybe an entry in .dynamic, a
485 reference to a symbol only a new libc.so has...)
507 The loader exposes a list of TLS modules ([`struct TlsModules`][TlsModules]) to `libc.so` using the
510 iterates its module list to lazily allocate and free TLS blocks.
523 `LinkerMemoryAllocator`, adapted to avoid the STL and to provide `memalign`. The prototype tries to
526 There are three "entry points" to dynamically locate a TLS variable's address:
531 The loader's entry points need to call `__tls_get_addr`, which needs to allocate memory. Currently,
532 the prototype uses a [special function pointer] to call libc.so's `__tls_get_addr` from the loader.
537 like the Bionic loader ignores segments' alignment and aligns loaded libraries to 256 KiB. See
545 it's feasible. musl's function is AS-safe, but glibc's isn't (or wasn't). Google had a patch to make
556 probably need to acquire the same lock.
567 > up the process. It would be a waste of memory and time to allocate the storage for all threads. A
568 > lazy method is wanted. This is not much extra burden since the requirement to handle dynamically
570 > alternative to stopping all threads and allocating storage for all threads before letting them run
578 most of it) also can't use ELF TLS. It might be possible to lift this restriction, perhaps with
588 TLS variant 1 allocates everything after the TP to ELF TLS (except the first two words), and variant
589 2 allocates everything before the TP. Bionic currently allocates memory before and after the TP to
602 ** linker and the OpenGL sub-system (which needs to access the
611 to use this slot for arm64 in 2016][D18632], though, and the slot isn't compatible with ARM's
620 * On arm32/arm64, it creates a pthread key, sets it to a magic value, then scans forward from
621 the thread pointer looking for it. [The scan count was bumped to 384 to fix a reported
639 * Android's "native bridge" system allows the Zygote to load an app solib of a non-native ABI. (For
640 example, it could be used to load an arm32 solib into an x86 Zygote.) The solib is translated
649 It seems easy to fix the incompatibility for variant 2 (x86 and x86_64) by splitting out the Bionic
657 variant 2 TLS, we might need to change the compiler to emit a sign-extending load.
677 The point of variant 2 was backwards-compatibility, and ARM Android needs to remain
680 * When linking an executable, the static linker needs to know how TLS is allocated because it
681 writes TP-relative offsets for IE/LE-model accesses. Clang doesn't tell the linker to target
682 Android, so it could pass an `--tls-variant2` flag to configure lld.
709 GCC for arm64 defaults to the 24-bit model and has an `-mtls-size=SIZE` option for setting other
714 The 16-, 32-, and 48-bit models use a `movn/movz` instruction to set the highest 16 bits to a
715 positive or negative value, then `movk` to set the remaining 16 bit chunks. In principle, these
716 relocations should be able to accommodate a negative TP offset.
718 The 24-bit model uses `add` to set the high 12 bits, then places the low 12 bits into another
721 Maybe we could modify the `R_AARCH64_TLSLE_ADD_TPREL_HI12` relocation to allow a negative TP offset
722 by converting the relocated `add` instruction to a `sub`. Alternately, we could add a new
726 * LLD's arm64 relaxations from GD and IE to LE would need to use `movn` instead of `movk` for
730 We might want to mark the binaries somehow to indicate the non-standard TLS ABI. Suggestion:
731 * Use an `--android-tls-variant2` flag (or `--bionic-tls-variant2`, we're trying to make [Bionic
744 Pros: Minimal linker change, no change to TLS relocations.
749 As with the first workaround, we'd probably want to mark the binary to indicate the non-standard
750 TP-to-TLS-segment offset.
753 * We would reserve at least 6 words to cover the stack guard
790 A likely problem: LD is normally relaxed to LE, not to IE. We'd either have to disable LD usage in
796 * Clang would need to stop generating LE accesses.
797 * LLD would need to relax GD and LD to IE instead of LE.
803 indicating IE in an solib, we want to indicate the lack of LE in an executable.
812 As a temporary compatibility hack, we might try to keep these programs running by reserving a TLS
813 slot with this magic value. This hack doesn't appear to work, however. The runtime finds its pthread
814 key, but apps segfault. Perhaps the Go runtime expects its "g" variable to be zero-initialized ([one
816 it is typically zero. After [Bionic's pthread key system was rewritten to be
834 somewhere (a global variable, another TLS slot, ...). `__get_thread()` already uses a TLS slot to
845 XXX: Maybe a sanitizer would want to intercept allocations of TLS memory, and that could be hard if
863 * ["Addenda to, and Errata in, the ABI for the ARM® Architecture."][arm-addenda] Section 3,