Lines Matching refs:thread

12 ELF TLS is a system for automatically allocating thread-local variables with cooperation among the
24 architecture-specific thread pointer (TP) and can be accessed very efficiently -- typically just a
31 architecture-specific thread-pointer ([`__get_tls()`] in Bionic):
42 thread-specific data layout, but variant 1 is more problematic than variant 2.
44 Each thread has a "Dynamic Thread Vector" (DTV) with a pointer to each module's TLS block (or NULL
108 1. If the current thread's DTV generation count is less than the current global TLS generation, then
176 // TPOFF is directly relative to the thread pointer.
220 In general, supporting surplus TLS memory probably requires maintaining a thread list so that
221 `dlopen` can initialize the new static TLS memory in all existing threads. A thread list could be
299 struct TlsDtv { // DTV == dynamic thread vector
369 Calling `dlsym` on a TLS variable returns the address of the current thread's variable.
375 gdb uses a libthread_db plugin library to retrieve thread-related information from a target. This
379 thread pointer (e.g. `ps_get_thread_area`).
390 anything: the `GetThreadPointer` function is no longer implemented. Code for reading the thread
427  * Read the target thread pointer.
428  * Use `_thread_db_pthread_dtvp` to find the thread's DTV.
440 There are ptrace interfaces for reading the thread pointer for each of arm32, arm64, x86, and x86-64
519 region, along with a thread's stack if it needs one allocated. It doesn't place TLS memory on a
520 preallocated stack (either the main thread's stack or one provided with `pthread_attr_setstack`).
565 > In addition the run-time support should avoid creating the thread-local storage if it is not
566 > necessary. For instance, a loaded module might only be used by one thread of the many which make
585 Bionic already allocates thread-specific data in a way that conflicts with TLS variants 1 and 2:
618  * The Go runtime allocates a thread-local "g" variable on Android by creating a pthread key and
621       the thread pointer looking for it. [The scan count was bumped to 384 to fix a reported
625     * On x86/x86-64, it uses a fixed offset from the thread pointer (TP+0xf8 or TP+0x1d0) and
632     * Moving the pthread keys before the thread pointer breaks Go-based apps.
785 the existing thread-specific memory layout untouched.
807 The Go runtime allocates its thread-local "g" variable by searching for a hard-coded magic constant
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