rethinking RTLD_NOW for loading plug-in modules

[Ken Raeburn]

On Apr 30, 2007, at 23:59, Nicolas Williams wrote:
>> 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.

That's what I thought.  (Though if one module wants to override  
symbol definitions in a shared library used by multiple modules, I  
suspect this could lead to some confusion based on the order of  
access of modules.)

>> 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.

Yes, I understand.  My point was that for any of them that are shared  
by more than one module, the penalty would only be paid once.  If you  
open multiple modules at once, as I'd expect you would do with SPNEGO  
or if you have to search all modules for a mechanism OID, the cost  
isn't N times the cost of resolving all of libc, plus M times the  
cost of resolving libkrb5, etc.  (Though libc may well be the only  
part shared between them, sometimes.)

I just want to get a clearer picture of what the penalty is, given  
that loading and using a module with undefined symbols may have a  
penalty of the program crashing.

Ken