Lines Matching refs:linker

13 compiler, linker, dynamic loader, and libc.
40 an executable, the linker needs to know where an executable's TLS segment is relative to the TP so
320 The static linker can still relax a TLSDESC-based access to an IE/LE access.
324  * GCC and the BFD linker support both designs on all supported Android architectures (arm32, arm64,
333 The (static) linker frequently has more information about the location of a referenced TLS variable
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
487 …ation]: https://android.googlesource.com/platform/bionic/+/android-8.1.0_r48/linker/linker.cpp#2852
489 …nored]: https://android.googlesource.com/platform/bionic/+/android-8.1.0_r48/linker/linker.cpp#2784
508 `__libc_shared_globals` variable (see `tls_modules()` in [linker_tls.cpp][tls_modules-linker] and
513 [tls_modules-linker]: https://android-review.googlesource.com/c/platform/bionic/+/723698/1/linker/l…
559 though, because Bionic (at least the linker) probably already aborts on OOM. musl doesn't support
602  ** linker and the OpenGL sub-system (which needs to access the
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
712    because no linker supported them: [BFD], [Gold], [LLD]).
744 Pros: Minimal linker change, no change to TLS relocations.
788 problem, because the linker and `libc.a` are usually packaged together.
801  * Perhaps LLD should mark executables specially, because a normal ELF linker's output would quietly
870    describing arm64 code sequences necessary for linker relaxation