This is the mail archive of the
mailing list for the GCC project.
Re: Duplicate data objects in shared libraries
>>>>> "David" == David Abrahams <email@example.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 <firstname.lastname@example.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
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
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.