mirror of
https://sourceware.org/git/glibc.git
synced 2024-11-14 01:00:07 +00:00
6985865bc3
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 1df71d32fe ("elf: Implement
force_first handling in _dl_sort_maps_dfs (bug 28937)").
Reviewed-by: DJ Delorie <dj@redhat.com>
67 lines
2.7 KiB
Modula-2
67 lines
2.7 KiB
Modula-2
# DSO sorting test descriptions.
|
|
# This file is to be processed by ../scripts/dso-ordering-test.py, see usage
|
|
# in elf/Makefile for how it is executed.
|
|
|
|
# We test both dynamic loader sorting algorithms
|
|
tunable_option: glibc.rtld.dynamic_sort=1
|
|
tunable_option: glibc.rtld.dynamic_sort=2
|
|
|
|
# Sequence of single dependencies with no cycles.
|
|
tst-dso-ordering1: a->b->c
|
|
output: c>b>a>{}<a<b<c
|
|
|
|
# Sequence including 2 dependent DSOs not at the end of the graph.
|
|
tst-dso-ordering2: a->b->[cd]->e
|
|
output: e>d>c>b>a>{}<a<b<c<d<e
|
|
|
|
# Complex order with 3 "layers" of full dependencies
|
|
tst-dso-ordering3: a->[bc]->[def]->[gh]->i
|
|
output: i>h>g>f>e>d>c>b>a>{}<a<b<c<d<e<f<g<h<i
|
|
|
|
# Sequence including 2 dependent DSOs at the end of the graph.
|
|
# Additionally the same dependencies appear in two paths.
|
|
tst-dso-ordering4: a->b->[de];a->c->d->e
|
|
output: e>d>c>b>a>{}<a<b<c<d<e
|
|
|
|
# Test that b->c cross link is respected correctly
|
|
tst-dso-ordering5: a!->[bc]->d;b->c
|
|
output: d>c>b>a>{}<a<b<c<d
|
|
|
|
# First DSO fully dependent on 4 DSOs, with another DSO at the end of chain.
|
|
tst-dso-ordering6: a->[bcde]->f
|
|
output: f>e>d>c>b>a>{}<a<b<c<d<e<f
|
|
|
|
# Sequence including 2 dependent and 3 dependent DSOs, and one of the
|
|
# dependent DSOs is dependent on an earlier DSO.
|
|
tst-dso-ordering7: a->[bc];b->[cde];e->f
|
|
output: f>e>d>c>b>a>{}<a<b<c<d<e<f
|
|
|
|
# Sequence where the DSO c is unerlinked and calls a function in DSO a which
|
|
# is technically a cycle. The main executable depends on the first two DSOs.
|
|
# Note: This test has unspecified behavior.
|
|
tst-dso-ordering8: a->b->c=>a;{}->[ba]
|
|
output: c>b>a>{}<a<b<c
|
|
|
|
# Generate the permutation of DT_NEEDED order between the main binary and
|
|
# all 5 DSOs; all link orders should produce exact same init/fini ordering
|
|
tst-dso-ordering9: a->b->c->d->e;{}!->[abcde]
|
|
output: e>d>c>b>a>{}<a<b<c<d<e
|
|
|
|
# Test if init/fini ordering behavior is proper, despite main program with
|
|
# an soname that may cause confusion
|
|
tst-dso-ordering10: {}->a->b->c;soname({})=c
|
|
output: b>a>{}<a<b
|
|
|
|
# Complex example from Bugzilla #15311, under-linked and with circular
|
|
# relocation(dynamic) dependencies. For both sorting algorithms, the
|
|
# destruction order is the reverse of the construction order, and
|
|
# relocation dependencies are not taken into account.
|
|
tst-bz15311: {+a;+e;+f;+g;+d;%d;-d;-g;-f;-e;-a};a->b->c->d;d=>[ba];c=>a;b=>e=>a;c=>f=>b;d=>g=>c
|
|
output: {+a[d>c>b>a>];+e[e>];+f[f>];+g[g>];+d[];%d(b(e(a()))a()g(c(a()f(b(e(a()))))));-d[];-g[];-f[];-e[];-a[<g<f<e<a<b<c<d];}
|
|
|
|
# Test that even in the presence of dependency loops involving dlopen'ed
|
|
# object, that object is initialized last (and not unloaded prematurely).
|
|
# Final destructor order is the opposite of constructor order.
|
|
tst-bz28937: {+a;+b;-b;+c;%c};a->a1;a->a2;a2->a;b->b1;c->a1;c=>a1
|
|
output: {+a[a2>a1>a>];+b[b1>b>];-b[<b<b1];+c[c>];%c(a1());}<c<a<a1<a2
|