Re: fixing libpthread noload, another approach

[David Laight <david%l8s.co.uk@localhost>]

On Sun, Feb 03, 2013 at 07:28:14AM +0100, Emmanuel Dreyfus wrote:
> 
> Here is another proposal: modify dlopen() so that instead of raising an
> error when encountering an object tagged with NOLOAD, it just resolves
> its symbol to an error stub. Therefore we are able to dlopen() a DSO
> linked with -lpthread, but libpthread is not loaded. If we do not use
> thread-related stuff, everything is fine, but if we call a function from
> libpthread, we abort with a diagnostic.
> 
> The advantage is that there is no performance hit for programs not
> linked with -lpthread: we leave the libc thread stub as no-ops. The
> overhead only happens in dlopen() when we have to load and unload an
> object that has the NOLOAD flag.

I presume that (effectively) forces RTLD_LAZY so you get the standard
error when the PLT code fails to look up the sysmbol?

That is just going to cause another splat of grief an a few months time.
dlopen() failing probably gets logged sensibly.
PLT functions failing to resolve names generates a horrid error exit.
It will be even less obvious why things aren't working.

        David

-- 
David Laight: david%l8s.co.uk@localhost