This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Duplicate data objects in shared libraries
>>>>> "H" == H J Lu <hjl@lucon.org> writes:
> On Mon, May 20, 2002 at 05:12:19PM +0100, Jason Merrill wrote:
>>
>> 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.
> 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 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.
> If you were saying:
> 1. Load C.so with RTLD_LOCAL.
> 2. Load A.so with RTLD_LOCAL.
> 3. Load B.so with RTLD_LOCAL.
> both A.so and B.so should resolve to C.so, 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 A.so and B.so 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.
Jason