diff options
| author | Florian Weimer <fweimer@redhat.com> | 2023-05-30 13:25:50 +0200 |
|---|---|---|
| committer | Florian Weimer <fweimer@redhat.com> | 2023-05-30 13:25:50 +0200 |
| commit | d0f07f7df8d9758c838674b70144ac73bcbd1634 (patch) | |
| tree | bf73fe79a9c8491aa6646a5b194c57e20b6a0871 /elf/dl-lookup.c | |
| parent | 3eed5f3a1ee356969afb403a1cf18d06f8d2d98a (diff) | |
| download | glibc-d0f07f7df8d9758c838674b70144ac73bcbd1634.zip glibc-d0f07f7df8d9758c838674b70144ac73bcbd1634.tar.gz glibc-d0f07f7df8d9758c838674b70144ac73bcbd1634.tar.bz2 | |
elf: Make more functions available for binding during dlclose (bug 30425)
Previously, after destructors for a DSO have been invoked, ld.so refused
to bind against that DSO in all cases. Relax this restriction somewhat
if the referencing object is itself a DSO that is being unloaded. This
assumes that the symbol reference is not going to be stored anywhere.
The situation in the test case can arise fairly easily with C++ and
objects that are built with different optimization levels and therefore
define different functions with vague linkage.
Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Diffstat (limited to 'elf/dl-lookup.c')
| -rw-r--r-- | elf/dl-lookup.c | 21 |
1 files changed, 19 insertions, 2 deletions
diff --git a/elf/dl-lookup.c b/elf/dl-lookup.c index 05f36a2..a8f48fe 100644 --- a/elf/dl-lookup.c +++ b/elf/dl-lookup.c @@ -366,8 +366,25 @@ do_lookup_x (const char *undef_name, unsigned int new_hash, if ((type_class & ELF_RTYPE_CLASS_COPY) && map->l_type == lt_executable) continue; - /* Do not look into objects which are going to be removed. */ - if (map->l_removed) + /* Do not look into objects which are going to be removed, + except when the referencing object itself is being removed. + + The second part covers the situation when an object lazily + binds to another object while running its destructor, but the + destructor of the other object has already run, so that + dlclose has set l_removed. It may not always be obvious how + to avoid such a scenario to programmers creating DSOs, + particularly if C++ vague linkage is involved and triggers + symbol interposition. + + Accepting these to-be-removed objects makes the lazy and + BIND_NOW cases more similar. (With BIND_NOW, the symbol is + resolved early, before the destructor call, so the issue does + not arise.). Behavior matches the constructor scenario: the + implementation allows binding to symbols of objects whose + constructors have not run. In fact, not doing this would be + mostly incompatible with symbol interposition. */ + if (map->l_removed && !(undef_map != NULL && undef_map->l_removed)) continue; /* Print some debugging info if wanted. */ |