Lines Matching refs:from

23 TLS Block". TLS variables within the Static TLS Block exist at fixed offsets from an
48 from TP is implementation-defined.
159 object), then its offset from the TP is known at load-time. The variable can be accessed with a few
187 part of the executable (and referenced from the executable), then a GOT access can be avoided. The
232 The code fragments above match the "traditional" TLS design from Drepper's document. For the GD and
375 gdb uses a libthread_db plugin library to retrieve thread-related information from a target. This
401 Both debuggers need metadata from the threading library (`libc.so` / `libpthread.so`) to find TLS
407 > expose the structure of the DTV via metadata exported as symbols from the .so itself, designed
416 `_thread_db_pthread_dtvp` | Offset from TP to DTV pointer (0 for variant 1, implementation-…
532 the prototype uses a [special function pointer] to call libc.so's `__tls_get_addr` from the loader.
620 * On arm32/arm64, it creates a pthread key, sets it to a magic value, then scans forward from
625 * On x86/x86-64, it uses a fixed offset from the thread pointer (TP+0xf8 or TP+0x1d0) and
685 offsets from TP:
726 * LLD's arm64 relaxations from GD and IE to LE would need to use `movn` instead of `movk` for
781 is located at a statically-known offset from the TP (i.e. it uses the LE model). An initially-loaded
784 LE, then the Bionic loader can place the executable's TLS segment at any offset from the TP, leaving
809 small positive offset from TP (within the first 384 words), it will think it has found the pthread
829 Go scans 384 words from the thread pointer. If there are at most 16 Bionic slots and 130 pthread
833 that pthread keys are at a fixed offset from the thread pointer anymore. It must load an offset from
869 * [2015 LLVM bugtracker comment][llvm22408] with an excerpt from an unnamed ARM draft specification