This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Duplicate data objects in shared libraries

>>>>> "David" == David Abrahams <> 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 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 <> 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, and here.

In this case, there are two dlopen groups: (, and (,

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

     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 as RTLD_GLOBAL after loading doesn't currently have the desired effect; the reference in is
still resolved locally.  Loading before works.

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

#4 as written above could have the effect of causing to refer to
a definition in, which would be problematic if we try to unload
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 and to refer to
the definition in, regardless of the order of loading.  I like it.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]