rethinking RTLD_NOW for loading plug-in modules

[Nicolas Williams]

On Mon, Apr 30, 2007 at 11:45:56PM -0400, Ken Raeburn wrote:
> On Apr 30, 2007, at 20:45, Tom Yu wrote:
> > I was doing some RTLD debugging traces on Solaris, and it appears that
> > for Solaris (and probably other dlopen()-supporting systems), loading
> > a shared object using dlopen() with the RTLD_NOW flag potentially
> > incurs the substantial performance penalty of immediately resolving
> > all symbol references in the opened object and all its dependencies.
> > If we combine this fact with the requirement for a shared object to
> > declare all of its dependencies (which is necessary in the case of
> > passing RTLD_GROUP to dlopen() or building modules using direct
> > binding), this likely means immediately resolving all symbol
> > references in libc.
> 
> Do you wind up with more than one copy of libc mapped in?  Or does  

No.  You can only do that sort of thing if you use separate link maps
(see dlmopen(3C), which you don't want to use for this kind of
application :), or if you have multiple different versions of given
shared object.  In the latter case symbol resolution after that will
greatly depend on whether RTLD_LOCAL and RTLD_GROUP were used.

> this part of the penalty, resolving the libc references, only happen  
> with the first libc-using object opened with RTLD_NOW?

It's not just libc -- all dependencies of an object opened with RTLD_NOW
will be opened and all relocations will be perfomed recursively until
all relocations in the object have been done and in the object's
dependencies, and their dependencies, ..., even though most of these
relocations may never be needed.

Nico
--