[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Duplicate data objects in shared libraries
From:       Michael Matz <matzmich () cs ! tu-berlin ! de>
Date:       2002-05-20 21:32:13
[Download RAW message or body]

Hi,

On Mon, 20 May 2002, Jason Merrill wrote:

> Perhaps the right approach is
>
> 5) Do not allow an object loaded with RTLD_LOCAL to override symbols from a
>    dependency.

Yep.  And indeed I ever thought this is how RTLD_LOCAL should behave.  A
"local" DSO can access it's own symbols and additionally those from the
global DSO's and the app.  Nothing except that local DSO can resolve to
it's own symbols (besides through an explicit dlsym() ).  If a global and
a local DSO both define the same symbol, the one from the global DSO is
used (even from inside the local one).  This partitions the application
into one big global chunk, and many local finals.  I think this is also
how dynamically loaded DSO's are used.  If you use RTLD_LOCAL you often
have the notion of a "plugin", with a fairly small and exactly
defined interface (i.e. not interfacing through global data, depending on
sharing of symbols).

In the past I once thought, that it would be ideal if we had another class
of symbols visibility: "global-damnit".  Such symbols are normal global
ones in RTLD_GLOBAL DSOs, and are also global with RTLD_LOCAL, just that
the dynamic linker magically ensures, that those symbol sets are made
disjoint when loading two such local DSOs into the same process.

This visibility would be reserved for language implementation symbols,
were the user really doesn't care how exactly they are spelled (or doesn't
even know they exist), but the language runtime cares, that they exist and
are different.  This would e.g. allow equally named classes in two
different local DSO still have different RTTI, as semantically they have
(sure technically you are outside standard with this and the
one-definition rule, but it should still work).

I think only this or a similar basic change to ELF (or other systems)
really would solve such problems correctly.  After all, the user wants to
write a plugin, say only exporting an "init" function returning an
instance of a (private) class deriving from a common "Plugin" class
(globally defined) which fixes the interface.  This plugin should be
loadable RTLD_LOCAL to not conflict with other plugins _in the symbols the
programmer actually wrote himself_, regardless of how the language is
implemented.  And still the user should be able to use all C++ features
reasonable (i.e. throwing exception into the global code, using templates,
whatnot.  Expecting that a static data from that local DSO is somehow
shared with other local DSOs, or even with the global part is not
reasonable here, it's local after all, i.e. invisible from the outside).


Ciao,
Michael.

[prev in list] [next in list] [prev in thread] [next in thread]