[Bug dynamic-link/20972] Running libc.so.6 as an executable triggers IFUNC relocation ordering issues

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20972

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #5 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Florian Weimer from comment #4)
> Dependency sorting always puts the main executable first, under the
> assumption that nothing can have a DT_NEEDED dependency on it.
> 
> When libc.so.6 is executed as an executable, it takes that position, rather
> than its usual position in the dependency order.
> 
> Relocation of objects precedes in a depth-first order.  This means that
> libpthread.so.0 is relocated before the main executable (libc.so.6 in this
> case).
> 
> Relocation processing for the __gettimeofday symbol reference in
> libpthread.so.0 calls the IFUNC resolver for this symbol in libc.so.6.
> 
> However, libc.so.6 has not been relocated at this point, and the reference
> to _rtld_global_ro (behind the GLRO macro) is undefined.
> 
> So in short, this is another IFUNC ordering issue.  The good news is that
> this particular one can only happen if libc.so.6 is the main executable. 
> Otherwise, libc.so.6 is relocated before libpthread.so.0.
> 
> Shorter reproducer:
> 
> LD_PRELOAD=/lib64/libpthread.so.0 /lib64/libc.so.6

The libesets_pac.so is preloaded and needs to have all of it's dependencies
initialized first. I think it's a dynamic loader bug that all the DT_NEEDED of
the preloaded DSO are not initialized first.

Though I agree this is a corner case, but one which we could fix with proper
dependency handling.

-- 
You are receiving this mail because:
You are on the CC list for the bug.