user/sven/glibc.git/include/link.h, branch master

Update copyright dates with scripts/update-copyrights

2026-01-01T21:42:29Z

misc: fix some typos

2025-12-02T12:25:36Z

Reviewed-by: Florian Weimer

elf: Restore support for _r_debug interpositions and copy relocations

2025-07-05T18:15:12Z

The changes in commit a93d9e03a31ec14405cb3a09aa95413b67067380 ("Extend struct r_debug to support multiple namespaces [BZ #15971]") break the dyninst dynamic instrumentation tool. It brings its own definition of _r_debug (rather than a declaration). Furthermore, it turns out it is rather hard to use the proposed handshake for accessing _r_debug via DT_DEBUG. If applications want to access _r_debug, they can do so directly if the relevant code has been built as PIC. To protect against harm from accidental copy relocations due to linker relaxations, this commit restores copy relocation support by adjusting both copies if interposition or copy relocations are in play. Therefore, it is possible to use a hidden reference in ld.so to access _r_debug. Only perform the copy relocation initialization if libc has been loaded. Otherwise, the ld.so search scope can be empty, and the lookup of the _r_debug symbol mail fail. Reviewed-by: H.J. Lu

Update copyright dates with scripts/update-copyrights

2025-01-01T19:22:09Z

elf: Avoid re-initializing already allocated TLS in dlopen (bug 31717)

2024-08-05T16:26:52Z

The old code used l_init_called as an indicator for whether TLS initialization was complete. However, it is possible that TLS for an object is initialized, written to, and then dlopen for this object is called again, and l_init_called is not true at this point. Previously, this resulted in TLS being initialized twice, discarding any interim writes (technically introducing a use-after-free bug even). This commit introduces an explicit per-object flag, l_tls_in_slotinfo. It indicates whether _dl_add_to_slotinfo has been called for this object. This flag is used to avoid double-initialization of TLS. In update_tls_slotinfo, the first_static_tls micro-optimization is removed because preserving the initalization flag for subsequent use by the second loop for static TLS is a bit complicated, and another per-object flag does not seem to be worth it. Furthermore, the l_init_called flag is dropped from the second loop (for static TLS initialization) because l_need_tls_init on its own prevents double-initialization. The remaining l_init_called usage in resize_scopes and update_scopes is just an optimization due to the use of scope_has_map, so it is not changed in this commit. The isupper check ensures that libc.so.6 is TLS is not reverted. Such a revert happens if l_need_tls_init is not cleared in _dl_allocate_tls_init for the main_thread case, now that l_init_called is not checked anymore in update_tls_slotinfo in elf/dl-open.c. Reported-by: Jonathon Anderson Reviewed-by: Carlos O'Donell

Update copyright dates with scripts/update-copyrights

2024-01-01T18:53:40Z

Revert "elf: Always call destructors in reverse constructor order (bug 30785)"

2023-10-18T09:30:38Z

This reverts commit 6985865bc3ad5b23147ee73466583dd7fdf65892. Reason for revert: The commit changes the order of ELF destructor calls too much relative to what applications expect or can handle. In particular, during process exit and _dl_fini, after the revert commit, we no longer call the destructors of the main program first; that only happens after some dlopen'ed objects have been destructed. This robs applications of an opportunity to influence destructor order by calling dlclose explicitly from the main program's ELF destructors. A couple of different approaches involving reverse constructor order were tried, and none of them worked really well. It seems we need to keep the dependency sorting in _dl_fini. There is also an ambiguity regarding nested dlopen calls from ELF constructors: Should those destructors run before or after the object that called dlopen? Commit 6985865bc3ad5b2314 used reverse order of the start of ELF constructor calls for destructors, but arguably using completion of constructors is more correct. However, that alone is not sufficient to address application compatibility issues (it does not change _dl_fini ordering at all).

elf: Remove unused l_text_end field from struct link_map

2023-09-08T16:39:20Z

It is a left-over from commit 52a01100ad011293197637e42b5be1a479a2 ("elf: Remove ad-hoc restrictions on dlopen callers [BZ #22787]"). When backporting commmit 6985865bc3ad5b23147ee73466583dd7fdf65892 ("elf: Always call destructors in reverse constructor order (bug 30785)"), we can move the l_init_called_next field to this place, so that the internal GLIBC_PRIVATE ABI does not change. Reviewed-by: Carlos O'Donell Tested-by: Carlos O'Donell

elf: Always call destructors in reverse constructor order (bug 30785)

2023-09-08T10:34:27Z

The current implementation of dlclose (and process exit) re-sorts the link maps before calling ELF destructors. Destructor order is not the reverse of the constructor order as a result: The second sort takes relocation dependencies into account, and other differences can result from ambiguous inputs, such as cycles. (The force_first handling in _dl_sort_maps is not effective for dlclose.) After the changes in this commit, there is still a required difference due to dlopen/dlclose ordering by the application, but the previous discrepancies went beyond that. A new global (namespace-spanning) list of link maps, _dl_init_called_list, is updated right before ELF constructors are called from _dl_init. In dl_close_worker, the maps variable, an on-stack variable length array, is eliminated. (VLAs are problematic, and dlclose should not call malloc because it cannot readily deal with malloc failure.) Marking still-used objects uses the namespace list directly, with next and next_idx replacing the done_index variable. After marking, _dl_init_called_list is used to call the destructors of now-unused maps in reverse destructor order. These destructors can call dlopen. Previously, new objects do not have l_map_used set. This had to change: There is no copy of the link map list anymore, so processing would cover newly opened (and unmarked) mappings, unloading them. Now, _dl_init (indirectly) sets l_map_used, too. (dlclose is handled by the existing reentrancy guard.) After _dl_init_called_list traversal, two more loops follow. The processing order changes to the original link map order in the namespace. Previously, dependency order was used. The difference should not matter because relocation dependencies could already reorder link maps in the old code. The changes to _dl_fini remove the sorting step and replace it with a traversal of _dl_init_called_list. The l_direct_opencount decrement outside the loader lock is removed because it appears incorrect: the counter manipulation could race with other dynamic loader operations. tst-audit23 needs adjustments to the changes in LA_ACT_DELETE notifications. The new approach for checking la_activity should make it clearer that la_activty calls come in pairs around namespace updates. The dependency sorting test cases need updates because the destructor order is always the opposite order of constructor order, even with relocation dependencies or cycles present. There is a future cleanup opportunity to remove the now-constant force_first and for_fini arguments from the _dl_sort_maps function. Fixes commit 1df71d32fe5f5905ffd5d100e5e9ca8ad62 ("elf: Implement force_first handling in _dl_sort_maps_dfs (bug 28937)"). Reviewed-by: DJ Delorie

Update copyright dates with scripts/update-copyrights

2023-01-06T21:14:39Z