This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Duplicate data objects in shared libraries
On Mon, May 20, 2002 at 06:12:35AM +0100, Jason Merrill wrote:
> Let me try to summarize the discussion:
>
> The semantics of existing SVR4 dynamic linkers are such that:
> IF two shared objects A.so and B.so link against the same shared
> library C.so, AND
> both override the same symbol S, AND
> A.so and B.so are loaded in that order with RTLD_LOCAL, THEN
> all references to S from A.so and C.so will resolve to the copy from
> A.so, but references from B.so will resolve to the copy from B.so.
>
> This is true because:
> There is only one copy of C.so loaded, and its relocs are only resolved
> once, AND
> the definitions from A.so and C.so are not visible when loading B.so.
>
> This breaks RTTI matching, which relies on all references within a
> program resolving to the same copy. Since references from B.so and C.so
> differ, this premise is violated.
>
> It is generally agreed that this is unfortunate. Yes?
>
> Various solutions present themselves. Most basically, they break down to:
>
> 1) Change the dynamic linker so that B.so and C.so agree, AND/OR
> 2) Change the runtime so that it doesn't matter if they don't agree.
>
>
> Possible implementations of #1:
> 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.
>
> I think #3 is philosophically cleaner.
>
> Have I missed any arguments?
>
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.
H.J.