Unnamed repository; edit this file 'description' to name the repository. http://euandre.org/git/grovel/atom?h=main 2023-11-07T02:50:37Z 2023-11-07T02:50:37Z Rich Felker dalias@aerifal.cx 2023-11-07T02:50:37Z urn:sha1:e17b9d74740df413fae2502c0010591c7998c40d presently this only affects 32-bit arm. despite correctly reversing the function pointer and argument fields based on the TLSDESC_BACKWARDS macro, we did not read the addend from the swapped-order argument field, so nonzero addends were lost, producing wrong runtime addresses for TLS objects needing an addend. based on report and patch by Rui Ueyama. 2023-11-07T02:48:02Z Rich Felker dalias@aerifal.cx 2023-11-07T02:48:02Z urn:sha1:039d3c34f2e3578a8b7ada42f89213b844aa7a4e this style is preferred because it allows the code to be compile-checked even on archs where it is not used. 2023-11-06T17:59:34Z Rich Felker dalias@aerifal.cx 2023-11-06T17:59:34Z urn:sha1:5baf2d92d3ed82960c419cb6093fbcdd028dde11 previously, the relative load address was used as the address at which to find the ELF headers. this only works if two conditions are met: ldso is linked to start at a virtual address of 0, and the linker is cooperative and includes the main ELF headers in a loadable segment. while in practice these are always met, modern linkers provide a __ehdr_start symbol pointing to the ELF headers, and can in principle use the reference to this symbol as an indication that they need to be mapped in a segment. this also should make it possible to link for a different starting virtual address, if that's ever desirable. 2023-04-11T13:06:27Z Rich Felker dalias@aerifal.cx 2023-04-11T13:06:27Z urn:sha1:7c41047285a24a97e700b4fb5b6b69f4505e2d82 commit 246f1c811448f37a44b41cd8df8d0ef9736d95f4 inadvertently introduced the local variable p as static by declaring it together with lfs64_list. the function is only reachable under lock, and is not called reentrantly, so this is not a functional bug, but it is confusing and inefficient. fix by separating the declarations. 2023-01-18T15:32:14Z Rich Felker dalias@aerifal.cx 2023-01-18T15:32:14Z urn:sha1:f897461d4fe72bb71854a6d0662de83008caccb7 mips has its own mechanisms for DT_DEBUG because it makes _DYNAMIC read-only, and the original mechanism, DT_MIPS_RLD_MAP, was PIE-incompatible. DT_MIPS_RLD_MAP_REL was added to remedy this, but we never implemented support for it. add it now using the same idioms for mips-specific ldso logic. 2022-12-01T00:07:34Z Rich Felker dalias@aerifal.cx 2022-11-30T23:59:08Z urn:sha1:f47a8cdd250d9163fcfb39bf4e9d813957c0b187 when PAGE_SIZE is not constant, internal/libc.h defines it to expand to libc.page_size. however, kernel_mapped_dso, reachable from stage 2 of the dynamic linker bootstrap (__dls2), needs PAGE_SIZE to interpret the relro range. at this point the libc object is both uninitialized and invalid to access according to our model for bootstrapping, which does not assume any external-linkage objects are accessible until stages 2b/3. in practice it likely worked because hidden visibility tends to behave like internal linkage, but this is not a property that the dynamic linker was designed to rely upon. this bug likely manifested as relro malfunction on archs with variable page size, due to incorrect mask when aligning the relro bounds to page boundaries. while there are certainly more direct ways to fix the known problem point here, a maximally future-proof way is to just bypass the libc.h PAGE_SIZE definition in the dynamic linker and instead have dynlink.c define its own internal-linkage object for variable page size. then, if anything else in stage 2 ever ends up referencing PAGE_SIZE, it will just automatically work right. 2022-11-10T14:02:02Z Rich Felker dalias@aerifal.cx 2022-11-10T14:02:02Z urn:sha1:29e4319178cbc2a4e9f058a99ae8098d4b6ac055 this is analogous to skip_relative logic in do_relocs -- because relative relocations for the dynamic linker itself were already performed at entry (stage 1), they must not be applied again. 2022-10-19T18:01:31Z Rich Felker dalias@aerifal.cx 2022-09-26T21:14:18Z urn:sha1:246f1c811448f37a44b41cd8df8d0ef9736d95f4 originally the namespace-infringing "large file support" interfaces were included as part of glibc-ABI-compat, with the intent that they not be used for linking, since our off_t is and always has been unconditionally 64-bit and since we usually do not aim to support nonstandard interfaces when there is an equivalent standard interface. unfortunately, having the symbols present and available for linking caused configure scripts to detect them and attempt to use them without declarations, producing all the expected ill effects that entails. as a result, commit 2dd8d5e1b8ba1118ff1782e96545cb8a2318592c was made to prevent this, using macros to redirect the LFS64 names to the standard names, conditional on _GNU_SOURCE or _LARGEFILE64_SOURCE. however, this has turned out to be a source of further problems, especially since g++ defines _GNU_SOURCE by default. in particular, the presence of these names as macros breaks a lot of valid code. this commit removes all the LFS64 symbols and replaces them with a mechanism in the dynamic linker symbol lookup failure path to retry with the spurious "64" removed from the symbol name. in the future, if/when the rest of glibc-ABI-compat is moved out of libc, this can be removed. 2022-09-12T12:30:36Z Rich Felker dalias@aerifal.cx 2022-09-12T12:30:36Z urn:sha1:6f3ead0ae16deb9f0004b275e29a276c9712ee3c commit d32dadd60efb9d3b255351a3b532f8e4c3dd0db1 added DT_RELR processing for programs and shared libraries processed by the dynamic linker, but left them unsupported in the dynamic linker itseld and in static pie binaries, which self-relocate via code in dlstart.c. add the equivalent processing to this code path so that there are not arbitrary restrictions on where the new packed relative relocation form can be used. 2022-08-17T23:49:54Z Érico Nogueira ericonr@disroot.org 2022-08-15T18:14:25Z urn:sha1:379b18218d18a049b5423bbb9bb22e066ffc3f78 breaking out of the switch-case when l==-1 means the conditional below will necessarily be true (-1 >= buf_size, a size_t variable) and the function will return 0. it is, however, somewhat unclear that that's what's happening. simply returning there is simpler