[pushed] Remove all loaded objects if dlopen fails, ignoring NODELETE [BZ #20839]
Commit Message
* 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?
Thanks,
Florian
Comments
On 02/12/2019 12:17, Florian Weimer wrote:
> * Szabolcs Nagy:
>> 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?
yes, this patch fixes the issue.
> 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
>
@@ -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