Re: Duplicate data objects in shared libraries

[Jason Merrill <jason at redhat dot com>]

>>>>> "David" == David Abrahams <david.abrahams@rcn.com> writes:

>> 3) If a library needed by an RTLD_LOCAL object is already loaded, ignore
>> it and map a new copy.  As an optimization, only do this if it refers to
>> symbols defined by the RTLD_LOCAL object.

>> 4) If a library needed by an RTLD_LOCAL object is already loaded, force
>> the library to RTLD_GLOBAL status so that references from B.so will use
>> the already-resolved definition.

> #3 would be much worse for me than the status quo is. The scenario is that
> my clients are writing extension modules loaded with RTLD_LOCAL. In order
> to function properly, these modules must share a copy of a common library:
> each module "publishes" some data through calls to the common library and
> also "subscribes" to all the data in the library. It sounds like ensuring
> that the library is actually shared in #3 would be next-to-impossible.

#3 comes from a conception of RTLD_LOCAL as a partitioning of the system
into independent parts ("programs", in earlier messages); if you want to
exchange information between two such objects via a common library, that
model is inadequate.

If you want RTLD_LOCAL objects to be able to share information, the
remaining option is to fix the sharing so it works properly, a la #4.

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

> I saw RTLD_GROUP in Solaris 8 dlopen man page and it says the scope of
> RTLD_LOCAL is for the dlopen group. I was wondering what the dlopen
> group meant and if it applied to A.so, B.so and C.so here.

In this case, there are two dlopen groups: (A.so, C.so) and (B.so, C.so).

The Solaris dlopen man page mentions something that could be taken as
relevant precedent:

                                                              Any
     object of mode RTLD_LOCAL that is referenced as a dependency
     of  an  object  of  mode  RTLD_GLOBAL  will  be  promoted to
     RTLD_GLOBAL. In other words, the RTLD_LOCAL mode is ignored.

My #4 is an extension of this principle.

Testing indicates that explicitly loading C.so as RTLD_GLOBAL after loading
A.so doesn't currently have the desired effect; the reference in B.so is
still resolved locally.  Loading C.so before A.so works.

Interestingly, loading C.so first as RTLD_LOCAL causes both A.so and B.so
to resolve to different addresses from C.so on Linux, but on Solaris it
produces the desired result.

#4 as written above could have the effect of causing B.so to refer to
a definition in A.so, which would be problematic if we try to unload A.so.
Perhaps the right approach is

5) Do not allow an object loaded with RTLD_LOCAL to override symbols from a
   dependency.

This rule is easily stated; it would cause both A.so and B.so to refer to
the definition in C.so, regardless of the order of loading.  I like it.

Jason