[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fixing libpthread noload, another approach
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 Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |