Re: dlopen "load order" ambiguity on POSIX tracker

["Carlos O'Donell" <carlos at redhat dot com>]

On 08/31/2015 03:47 PM, Rich Felker wrote:
> I've just posted the following on the POSIX issue tracker:
> 
> Ambiguity in dlopen's definition of "load order" for symbol resolution
> http://austingroupbugs.net/view.php?id=982
> 
> At Carlos' request I'm starting a thread here on libc-alpha too since
> the issue pertains to glibc's behavior. I think the current glibc
> behavior is generally correct, but it would be nice to have input from
> the glibc side. It's also possible that thought experiments about this
> ambiguity will turn up weird corner case bugs in glibc, e.g.
> interaction of the sort of example in this issue report with weak
> definitions or references, STB_GNU_UNIQUE, visibility, or other odd
> dynamic linker features outside the scope of POSIX.

I expect that there are many such "tought experiment" cases that simply
don't work in glibc, just look at the problems with dlmopen.

The behaviour in glibc is IMO the correct behaviour. The promotion of
the object to RTLD_GLOBAL places it last on the global search list,
and that preserves the search order in a sensible manner. That is to say
that objects that were loaded earlier with RTLD_GLOBAL will be searched
first.

The use of RTLD_GLOBAL to promote an RTLD_LOCAL object behaves as if you
had just loaded the object again, but you obviously didn't, and all the
constructors have already run etc. Therefore there is likely some
unintended side-effects of this, but we'll have to deal with them one
by one.

To be honest the testing of the loader is fair to poor in glibc. We need
far more test to start covering all of the interesting use cases we claim
to support.

Cheers,
Carlos.