Re: [pushed] Remove all loaded objects if dlopen fails, ignoring NODELETE [BZ #20839]

[Florian Weimer <fweimer@redhat.com>]

* Szabolcs Nagy:

> On 27/11/2019 20:30, Sourceware to Gerrit sync (Code Review) wrote:
>> Sourceware to Gerrit sync has submitted this change.
>> 
>> Change URL: https://gnutoolchain-gerrit.osci.io/r/c/glibc/+/471
>> ......................................................................
>> 
>> Remove all loaded objects if dlopen fails, ignoring NODELETE [BZ #20839]
>> 
>> This introduces a “pending NODELETE” state in the link map, which is
>> flipped to the persistent NODELETE state late in dlopen, via
>> activate_nodelete.    During initial relocation, symbol binding
>> records pending NODELETE state only.  dlclose ignores pending NODELETE
>> state.  Taken together, this results that a partially completed dlopen
>> is rolled back completely because new NODELETE mappings are unloaded.
>> 
>> Tested on x86_64-linux-gnu and i386-linux-gnu.
>> 
>> Change-Id: Ib2a3d86af6f92d75baca65431d74783ee0dbc292
>> ---
>> M elf/Makefile
>> M elf/dl-close.c
>> M elf/dl-lookup.c
>> M elf/dl-open.c
>> M elf/get-dynamic-info.h
>> A elf/tst-dlopenfail.c
>> A elf/tst-dlopenfaillinkmod.c
>> A elf/tst-dlopenfailmod1.c
>> A elf/tst-dlopenfailmod2.c
>> M include/link.h
>> 10 files changed, 328 insertions(+), 38 deletions(-)
>> 
>> Approvals:
>>   Carlos O'Donell: Looks good to me, approved
>
> i see
>
> FAIL: elf/tst-dlopenfail
>
> and
>
> $ cat elf/tst-dlopenfail.out
> info: attempting to load tst-dlopenfailmod1.so
> tst-dlopenfailmod1 constructor executed
>
> on the aarch64 buildbot

It's likely that your toolchain defaults to --no-as-needed.  Does this
patch fix things for you?

diff --git a/elf/Makefile b/elf/Makefile
index f825354d3f..0debea7759 100644
--- a/elf/Makefile
+++ b/elf/Makefile
@@ -1618,8 +1618,11 @@ LDFLAGS-tst-finilazyfailmod.so = \
 $(objpfx)tst-dlopenfail: $(libdl)
 $(objpfx)tst-dlopenfail.out: \
   $(objpfx)tst-dlopenfailmod1.so $(objpfx)tst-dlopenfailmod2.so
-# Order matters here.  tst-dlopenfaillinkmod.so's soname ensures
-# a run-time loader failure.
+# Order matters here.  tst-dlopenfaillinkmod.so's soname ensures a
+# run-time loader failure.  --as-needed breaks this test because
+# nothing actually references tst-dlopenfailmod2.so (with its soname
+# tst-dlopenfail-missingmod.so).
+LDFLAGS-tst-dlopenfailmod1.so = -Wl,--no-as-needed
 $(objpfx)tst-dlopenfailmod1.so: \
   $(shared-thread-library) $(objpfx)tst-dlopenfaillinkmod.so
 LDFLAGS-tst-dlopenfaillinkmod.so = -Wl,-soname,tst-dlopenfail-missingmod.so

Thanks,
Florian