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

>>>>> "H" == H J Lu <> writes:

> On Mon, May 20, 2002 at 05:12:19PM +0100, Jason Merrill wrote:
>> 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.

> It seems like a Linux bug. I will look into it if no one else does.

>> #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
>> dependency.
>> 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.

> If you were saying:

> 1. Load with RTLD_LOCAL.
> 2. Load with RTLD_LOCAL.
> 3. Load with RTLD_LOCAL.

> both and should resolve to, I think it makes sense.

Yes, that is what I was saying.  A possible refinement would be

6) #5, but if the definition in the RTLD_LOCAL object is strong, use it in
   the object.

Which would produce the current Linux semantics described above if the
definitions in and are strong, and the current Solaris semantics
described above if they are weak.  This would allow a plugin writer to
override operator new for their plugin without affecting uses in
libstdc++.  Obviously, the plugin writer would need to be careful to
handle all of their own memory allocation/deallocation.


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