[RFC][PATCH v1 0/5] Proof-of-Concept implementation of RTLD_SHARED for dlmopen

[Vivek Das Mohapatra]

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