This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][PATCH v1 0/5] Proof-of-Concept implementation of RTLD_SHARED for dlmopen
Now we have a few good win/win scenarios:
* You can now force objects into a dlmopen namespace even if you link
directly with them by setting DT_LMNS to a value other than $.*
You would have to look these objects up to use them via a namespaced
dl_iterate_phtr?
* You can add new objects to $PROXY if you want them to be exposed
through all of the namespaces too.
Thoughts?
- namespaced dl_iterate_phdr would make my life easier, so thumbs up.
- need to refresh my memory regarding dl_map_object - I think we'd need
to harvest this info in _dl_map_object_from_fd and set a flag in
the struct for easy checking later (or maybe keep a list of
must-proxy objects, sort of analogous to how RTLD_GLOBAL objects
are tracked, I guess).
Which reminds me - the code currently has a comment in it that says
RTLD_GLOBAL is nonsensical for namespaces but this isn't exactly true:
I think it makes sense for RTLD_GLOBAL to mean "use this for everything
in the target namesapace" (Mesa libGL for example RTLD_GLOBAL dlopens
_itself_ to export symbols to modules it is about to open, which I have
to trap when isolating libGL).
In effect, the $PROXY DT_LMNS DSOs become super-global (Solar?)
and RTLD_GLOBAL is extended to mean "for this namespace".