rethinking RTLD_NOW for loading plug-in modules
raeburn at MIT.EDU
Tue May 1 00:16:01 EDT 2007
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
> 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.
More information about the krbdev