Re: Duplicate data objects in shared libraries

["David Abrahams" <david dot abrahams at rcn dot com>]

From: "Jason Merrill" <jason@redhat.com>

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


Nice summary.

> It is generally agreed that this is unfortunate.  Yes?


I agree; I can't speak for others.

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

<snip>

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


#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, and
that even if it were possible my users could easily break sharing
unintentionally by using a some template, inline function or polymorphic
class which is also used by the library.

[I have managed, for the time being, to make my application immune to the
problem we're discussing at the top by arranging for certain exceptions
previously thrown by client code to to be thrown by a function call into
the common library... so they are thrown and caught in the same object. I
don't think such work-arounds will be available for some planned upcoming
work]

#4, or a variation on it, makes much more sense to me.

> Have I missed any arguments?


None that I wouldn't take issue with ;-)

> I am in favor of doing #1 and neutral to positive on #2.  As a possible
> point for further discussion, here is an unofficial patch I whipped up a
> week or so ago to do #2 iff -fpic.  YMMV.


Constructive!

Thanks,
Dave