ld.so: Adjust the auxv if ld.so is directly invoked.

If a binary gets invoked by passing it as argument to ld.so the stack
still holds the auxiliary vector of ld.so when entering the _start
routine of the executable.  So the invocation via ld.so is not fully
transparent to the executable.  This causes problems if the executable
wants to scan the auxv itself.

1 files changed, 5 insertions, 5 deletions

diff --git a/elf/dl-sysdep.c b/elf/dl-sysdep.c
index 49c5dfb..5507e57 100644
--- a/elf/dl-sysdep.c
+++ b/elf/dl-sysdep.c
@@ -85,7 +85,7 @@ void *_dl_random attribute_relro = NULL;
 ElfW(Addr)
 _dl_sysdep_start (void **start_argptr,
 		  void (*dl_main) (const ElfW(Phdr) *phdr, ElfW(Word) phnum,
-				   ElfW(Addr) *user_entry))
+				   ElfW(Addr) *user_entry, ElfW(auxv_t) *auxv))
 {
   const ElfW(Phdr) *phdr = NULL;
   ElfW(Word) phnum = 0;
@@ -241,7 +241,7 @@ _dl_sysdep_start (void **start_argptr,
   if (__builtin_expect (INTUSE(__libc_enable_secure), 0))
     __libc_check_standard_fds ();
 
-  (*dl_main) (phdr, phnum, &user_entry);
+  (*dl_main) (phdr, phnum, &user_entry, _dl_auxv);
   return user_entry;
 }
 
@@ -511,9 +511,9 @@ _dl_important_hwcaps (const char *platform, size_t platform_len, size_t *sz,
   /* Fill in the information.  This follows the following scheme
      (indeces from TEMP for four strings):
 	entry #0: 0, 1, 2, 3	binary: 1111
-	      #1: 0, 1, 3	        1101
-	      #2: 0, 2, 3	        1011
-	      #3: 0, 3		        1001
+	      #1: 0, 1, 3		1101
+	      #2: 0, 2, 3		1011
+	      #3: 0, 3			1001
      This allows the representation of all possible combinations of
      capability names in the string.  First generate the strings.  */
   result[1].str = result[0].str = cp = (char *) (result + *sz);