Lines Matching refs:an

23 TLS Block". TLS variables within the Static TLS Block exist at fixed offsets from an
40 an executable, the linker needs to know where an executable's TLS segment is relative to the TP so
114 If an allocation fails, `__tls_get_addr` calls `abort` (like emutls).
154 variable with a dynamic initializer has an associated TLS guard variable.)
158 If the variable is part of the Static TLS Block (i.e. the executable or an initially-loaded shared
162 Example: a C file for an executable:
197 ## Selecting an Access Model
199 The compiler selects an access model for each variable reference using these factors:
200  * The absence of `-fpic` implies an executable, so use IE/LE.
234 reference has a corresponding descriptor, which contains a resolver function address and an argument
289    need to use an atomic or synchronized access of the global TLS generation counter.
320 The static linker can still relax a TLSDESC-based access to an IE/LE access.
334 than the compiler, so it can "relax" TLS accesses to more efficient models. For example, if an
335 object file compiled with `-fpic` is linked into an executable, the linker could relax GD accesses
336 to IE or LE. To relax a TLS access, the linker looks for an expected sequences of instructions and
364 arm32 linkers can't relax traditional TLS accesses. BFD can relax an arm32 TLSDESC access, but LLD
434 read past the end of an out-of-date DTV or access an unloaded module. To be robust, it needs to
478  * On arm64, the primary TLS relocation (R_AARCH64_TLSDESC) is [confused with an obsolete
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
494 There is an [ELF TLS prototype] uploaded on Gerrit. It implements:
553 The prototype lazily allocates TLS memory for dlopen'ed modules (see `__tls_get_addr`), and an
560 `dlclose`/unloading, so it might have an easier time.
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
680  * When linking an executable, the static linker needs to know how TLS is allocated because it
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
731     * Use an `--android-tls-variant2` flag (or `--bionic-tls-variant2`, we're trying to make [Bionic
742 ### Workaround: Reserve an Extra-Large TCB on ARM
745 Cons: The reserved amount becomes an arbitrary but immutable part of the Android ABI.
747 Add an lld option: `--android-tls[-tcb=SIZE]`
759 ### Workaround: Use Variant 1 Everywhere with an Extra-Large TCB
780 The layout conflict is apparently only a problem because an executable assumes that its TLS segment
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.
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