elf: Partially initialize ld.so after static dlopen (bug 20802)

After static dlopen, a copy of ld.so is loaded into the inner
namespace, but that copy is not initialized at all.  Some
architectures run into serious problems as result, which is why the
_dl_var_init mechanism was invented.  With libpthread moving into
libc and parts into ld.so, more architectures impacted, so it makes
sense to switch to a generic mechanism which performs the partial
initialization.

As a result, getauxval now works after static dlopen (bug 20802).

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

1 files changed, 3 insertions, 8 deletions

diff --git a/dlfcn/tststatic5.c b/dlfcn/tststatic5.c
index 872e87fbaf..e0a50b7dcc 100644
--- a/dlfcn/tststatic5.c
+++ b/dlfcn/tststatic5.c
@@ -25,14 +25,9 @@
    mapped from a static executable.
 
    On targets that support different page sizes, the kernel communicates
-   the size currently in use via the auxiliary vector.  This vector is
-   available to initial startup, but not any DSOs loaded later on.  As
-   static executables do not export their symbols a DSO cannot access
-   the value obtained by initial startup and the value therefore has to
-   be passed on to the DSO and stored within its data area explicitly.
-   This is performed by a call to DL_STATIC_INIT that is defined in a
-   target-dependent way, and that on variable page size targets stores
-   it in the GLRO(dl_pagesize) variable of the DSO's dynamic linker.  */
+   the size currently in use via the auxiliary vector.  The auxiliary
+   vector and HWCAP/HWCAP2 bits are copied across the static dlopen
+   boundary in __rtld_static_init.  */
 static int
 do_test (void)
 {