Re: [PATCH] Save reference to kernel provided envp in the linker

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

> Right, that's why I figured that it's some relocation quirk (won't
> call it a bug till I prove it as such) that I haven't understood yet.
> Printing environ results in __environ being resolved.  It has the same
> effect in code, where referencing environ fixes the reference to
> __environ somehow.
> 

Sorry, I made a mistake in my testing earlier.  It does not have the
same effect in code.  The code shows all of them (__environ, environ,
_environ) as being in the same location and having the same value
(NULL).

Also, I looked at your gdb snippet again:

Breakpoint 1, elision_init (argc=1, argv=0x7fffffffe258,
    environ=0x7fffffffe268)
    at ../nptl/sysdeps/unix/sysv/linux/x86/multiarch/elision-conf.c:214
214     {
(gdb) bt
#0  elision_init (argc=1, argv=0x7fffffffe258, environ=0x7fffffffe268)
    at ../nptl/sysdeps/unix/sysv/linux/x86/multiarch/elision-conf.c:214
#1  0x00007ffff7de9966 in call_init (env=0x7fffffffe268, argv=0x7fffffffe258,
    argc=1, l=<optimized out>) at dl-init.c:84
#2  call_init (l=<optimized out>, argc=1, argv=0x7fffffffe258,
    env=0x7fffffffe268) at dl-init.c:34
#3  0x00007ffff7de9a67 in _dl_init (main_map=0x7ffff7ffe208, argc=1,
    argv=0x7fffffffe258, env=0x7fffffffe268) at dl-init.c:99
#4  0x00007ffff7ddc59a in _dl_start_user ()
   from /export/build/gnu/glibc-andi/build-x86_64-linux/elf/ld.so
#5  0x0000000000000001 in ?? ()
#6  0x00007fffffffe4dc in ?? ()
#7  0x0000000000000000 in ?? ()
(gdb) p *environ
$1 = 0x7fffffffe51d "TERM=xterm"
(gdb)

That's referencing the local variable environ and not the global.  I
assume you're referring to environ being passed as an argument to the
constructor?  I guess I could just modify
__pthread_initialize_minimal_internal to accept arguments and be done
with it.


Siddhesh