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

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 and link against the same shared 
>      library, AND
>    both override the same symbol S, AND
> and are loaded in that order with RTLD_LOCAL, THEN
>    all references to S from and will resolve to the copy from
>, but references from will resolve to the copy from
> This is true because:
>    There is only one copy of loaded, and its relocs are only resolved
>      once, AND
>    the definitions from and are not visible when loading
> This breaks RTTI matching, which relies on all references within a
> program resolving to the same copy.  Since references from and
> 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 and 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 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, and here.


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