summaryrefslogtreecommitdiff
path: root/src/ldso/x86_64
AgeCommit message (Collapse)AuthorLines
2019-02-18install dynamic tls synchronously at dlopen, streamline accessRich Felker-20/+1
previously, dynamic loading of new libraries with thread-local storage allocated the storage needed for all existing threads at load-time, precluding late failure that can't be handled, but left installation in existing threads to take place lazily on first access. this imposed an additional memory access and branch on every dynamic tls access, and imposed a requirement, which was not actually met, that the dynamic tlsdesc asm functions preserve all call-clobbered registers before calling C code to to install new dynamic tls on first access. the x86[_64] versions of this code wrongly omitted saving and restoring of fpu/vector registers, assuming the compiler would not generate anything using them in the called C code. the arm and aarch64 versions saved known existing registers, but failed to be future-proof against expansion of the register file. now that we track live threads in a list, it's possible to install the new dynamic tls for each thread at dlopen time. for the most part, synchronization is not needed, because if a thread has not synchronized with completion of the dlopen, there is no way it can meaningfully request access to a slot past the end of the old dtv, which remains valid for accessing slots which already existed. however, it is necessary to ensure that, if a thread sees its new dtv pointer, it sees correct pointers in each of the slots that existed prior to the dlopen. my understanding is that, on most real-world coherency architectures including all the ones we presently support, a built-in consume order guarantees this; however, don't rely on that. instead, the SYS_membarrier syscall is used to ensure that all threads see the stores to the slots of their new dtv prior to the installation of the new dtv. if it is not supported, the same is implemented in userspace via signals, using the same mechanism as __synccall. the __tls_get_addr function, variants, and dynamic tlsdesc asm functions are all updated to remove the fallback paths for claiming new dynamic tls, and are now all branch-free.
2015-04-17apply hidden visibility to tlsdesc accessor functionsRich Felker-0/+2
these functions are never called directly; only their addresses are used, so PLT indirections should never happen unless a broken application tries to redefine them, but it's still best to make them hidden.
2015-04-14use hidden __tls_get_new for tls/tlsdesc lookup fallback casesRich Felker-1/+3
previously, the dynamic tlsdesc lookup functions and the i386 special-ABI ___tls_get_addr (3 underscores) function called __tls_get_addr when the slot they wanted was not already setup; __tls_get_addr would then in turn also see that it's not setup and call __tls_get_new. calling __tls_get_new directly is both more efficient and avoids the issue of calling a non-hidden (public API/ABI) function from asm. for the special i386 function, a weak reference to __tls_get_new is used since this function is not defined when static linking (the code path that needs it is unreachable in static-linked programs).
2015-04-14use hidden visibility for call from dlsym to internal __dlsymRich Felker-0/+1
2015-04-13dynamic linker bootstrap overhaulRich Felker-16/+0
this overhaul further reduces the amount of arch-specific code needed by the dynamic linker and removes a number of assumptions, including: - that symbolic function references inside libc are bound at link time via the linker option -Bsymbolic-functions. - that libc functions used by the dynamic linker do not require access to data symbols. - that static/internal function calls and data accesses can be made without performing any relocations, or that arch-specific startup code handled any such relocations needed. removing these assumptions paves the way for allowing libc.so itself to be built with stack protector (among other things), and is achieved by a three-stage bootstrap process: 1. relative relocations are processed with a flat function. 2. symbolic relocations are processed with no external calls/data. 3. main program and dependency libs are processed with a fully-functional libc/ldso. reduction in arch-specific code is achived through the following: - crt_arch.h, used for generating crt1.o, now provides the entry point for the dynamic linker too. - asm is no longer responsible for skipping the beginning of argv[] when ldso is invoked as a command. - the functionality previously provided by __reloc_self for heavily GOT-dependent RISC archs is now the arch-agnostic stage-1. - arch-specific relocation type codes are mapped directly as macros rather than via an inline translation function/switch statement.
2014-06-20rename dynamic linker entry point from _start to _dlstartRich Felker-2/+2
the main motivation for this change is to aid in debugging. since the main program's entry point is also named _start, it was difficult to set breakpoints or quickly identify which _start execution stopped in.
2014-06-19add tlsdesc support for x86_64Rich Felker-0/+40
2012-05-27add ldd and main program loading support to dynamic linkerRich Felker-0/+8
2012-05-27cleanup dynamic linker start code cruftRich Felker-1/+0
two actual issues: one is that __dynlink no longer wants/needs a GOT pointer argument, so the code to generate that argument can be removed. the other issue was that in the i386 code, argc/argv were being loaded into registers that would be call-clobbered, then copied to preserved registers, rather than just being loaded into the proper call-preserved registers to begin with. this cleanup is in preparation for adding new dynamic linker functionality (ability to explicitly invoke the dynamic linker to run a program).
2011-09-03fix RTLD_NEXT on x86_64Rich Felker-1/+1
the return address was being truncated to 32 bits, preventing the dlsym code from determining which module contains the calling code.
2011-08-16RTLD_NEXT supportRich Felker-0/+6
the asm wrapper is needed to get the return address without compiler-specific extensions.
2011-06-19x86_64: ensure that dtor pointer passed to app is 0 so it won't be usedRich Felker-0/+1
leaving it uninitialized caused unpredictable crashes or worse due to calling an indeterminate function pointer.
2011-06-18experimental dynamic linker!Rich Felker-0/+8
some notes: - library search path is hard coded - x86_64 code is untested and may not work - dlopen/dlsym is not yet implemented - relocations in read-only memory won't work