Lines Matching refs:in
15 Thread-local variables are declared in C and C++ with a specifier, e.g.:
31 architecture-specific thread-pointer ([`__get_tls()`] in Bionic):
47 expected to point immediately at the DTV pointer, whereas in variant 2, the DTV pointer's offset
66 A TLS variable may be in a different module than the reference.
71 "traditional" non-TLSDESC design described in Drepper's TLS document, the toolchain compiler emits a
74 For example, if we have this C code in a shared object:
92 static TlsIndex tls_var_idx = { // allocated in the .got
104 `__tls_get_addr` looks up `TlsIndex::module`'s entry in the DTV and adds `TlsIndex::offset` to the
116 musl, on the other, preallocates TLS memory in `pthread_create` and in `dlopen`, and each can report
140 static TlsIndex tls_module_idx = { // allocated in the .got
165 // tls_var could be defined in the executable, or it could be defined
166 // in a shared object the executable links against.
174 // allocated in the .got, resolved at load-time with a dynamic reloc.
201 * Code compiled with `-fpic` could be in a shared object, so use GD/LD.
212 memory in the static TLS block. glibc reserves a kilobyte or two (`TLS_STATIC_SURPLUS`) with the
221 `dlopen` can initialize the new static TLS memory in all existing threads. A thread list could be
237 For example, if we have this C code in a shared object:
255 // allocated in the .got, uses a dynamic relocation
261 The dynamic loader fills in the TLS descriptors. For a reference to a variable allocated in the
283 almost all registers, reducing register pressure in the caller
291 The resolver must be written in assembly, but in C, the function looks like so:
377 gdbserver. We will need to implement at least 2 APIs in `libthread_db.a` to find TLS variables, and
381 * Reference: [Currently unimplemented TLS functions in Android's libthread_tb][libthread_db.c]
388 LLDB more-or-less implemented Linux TLS debugging in [r192922][rL192922] ([D1944]) for x86 and
391 pointer was removed in [D10661] ([this function][r240543]). (arm32 was apparently never supported.)
404 > ... All OSes use basically the same algorithm (a per-module lookup table) as detailed in Ulrich
408 > exactly for this kind of thing. So this patch simply reads that metadata in, and re-implements
421 The metadata variables are local symbols in glibc's `libpthread.so` symbol table (but not its
433 This process doesn't appear robust in the face of lazy DTV initialization -- presumably it could
453 `__thread` | - non-standard, but ubiquitous in GCC and Clang<br/> - cannot have dynamic initi…
454 `_Thread_local` | - a keyword standardized in C11<br/> - cannot have dynamic initialization or des…
462 efficient in C++ than `thread_local` when the compiler cannot see the definition of a declared TLS
483 marks, so running it on an older platform would result in memory corruption. Should we add something
484 to these executables that only newer platforms recognize? (e.g. maybe an entry in .dynamic, a
508 `__libc_shared_globals` variable (see `tls_modules()` in [linker_tls.cpp][tls_modules-linker] and
509 [elf_tls.cpp][tls_modules-libc]). `__tls_get_addr` in libc.so acquires the `TlsModules::mutex` and
518 The prototype currently allocates a `pthread_internal_t` object and static TLS in a single mmap'ed
536 implementations (glibc, musl, FreeBSD) vary in their level of respect for TLS alignment. It looks
546 glibc AS-safe back in 2012-2013. See:
563 solib's TLS variables. Drepper makes this argument in his TLS document:
575 ## ELF TLS Not Usable in libc
585 Bionic already allocates thread-specific data in a way that conflicts with TLS variants 1 and 2:
586 
611 to use this slot for arm64 in 2016][D18632], though, and the slot isn't compatible with ARM's
612 variant 1 layout. This change shipped in NDK r14, and the NDK's build systems (ndk-build and the
641 into the host architecture. TLS accesses in the app solib (whether ELF TLS, Bionic slots, or
656 (https://godbolt.org/z/_NIXjF). If Android ever supports this target, and in a configuration with
768 ### Workaround: No LE Model in Android Executables
790 A likely problem: LD is normally relaxed to LE, not to IE. We'd either have to disable LD usage in
799 * LLD must not statically resolve an executable's IE relocation in the GOT. (It might assume that
803 indicating IE in an solib, we want to indicate the lack of LE in an executable.
848 can interpose call in the loader: https://sourceware.org/ml/libc-alpha/2014-01/msg00501.html
863 * ["Addenda to, and Errata in, the ABI for the ARM® Architecture."][arm-addenda] Section 3,