Re: Minimal GCC/Linux shared lib + EH bug example

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

----- Original Message -----
From: "Sean Parent" <sparent@adobe.com>

> on 5/13/02 11:16 PM, Martin v. Loewis at martin@v.loewis.de wrote:
>
> > I believe that it is a useful approach to keep the notion that shared
> > libraries are part of a "program", and that the program still ought to
> > implement the semantics of the relevant standards. In this specific
> > case, any Python extension would be a "program" (though free-standing,
> > since it has a different entry point).
>
> By "shared" I will assume you mean "dynamically linked". Although I agree
> with the term "ought to" I'm unaware of any system which currently
behaves
> even remotely like this ideal. David's proposal, I believe amounts to
> requiring that dynamic linking is handled much more like static linking
with
> a resolution mechanism for duplicate symbols. This proposal would require
> significantly more sophisticated loaders (than current loaders which
usually
> do a very simple name binding).

Could you be more specific about the differences you are mentioning? It
seems to me that the current model is identical to static linking when all
the objects are linked to one another directly (i.e. no use of dlopen with
RTLD_LOCAL).

> This opens the question - is it necessary to force a new model for
loading
> libraries to get reasonable semantics for C++ dynamic linking?

It depends on your definition of "reasonable". If you want to support a
model which includes RTLD_LOCAL and doesn't add new restrictions on what
may be linked together, then I think the answer is yes.

> If the answer
> is "yes" then we will have a very difficult adoption going forward as the
> library loader is a relatively fundamental piece of any operating system.

It's not clear. I wonder whether any software that relies on the current
behavior (as opposed to what I'm proposing) can possibly work right. I
think the only legal programs that could be broken by the change I'm
proposing would be those that unload libraries, and I'm not even certain of
that: it depends on what the semantics of unloading are.

> Beyond those issue there is the fact that dynamically linked libraries
> currently provide a degree of encapsulation - and that encapsulation is a
> major reason developers use dynamic linking. Forcing a broad notion of
> symbol resolution potentially defeats many of the benefits.

I think if you look at my proposal closely, you'll see that it is fairly
conservative. It doesn't introduce any new concepts, just a small change to
the existing behavior which removes an order-dependency. Symbol sharing
across library boundaries would only happen where it would have happened
with the current semantics if the library load order were changed.

> > Unfortunately, apart from the obvious cases, it is pretty difficult to
> > give a well definition; it is much easier to declare problematic cases
> > as undefined. You probably cannot convince compiler vendors to follow
> > what you consider a reasonable semantics unless you specify what that
> > semantics is, and contribute code or money to change their
> > implementations.
>
> What are the obvious cases? The problematic cases in C++ includes aspects
> of, RTTI, exception handling, inline functions, templates, static
members,
> and memory allocation. This currently disqualifies all of the C++
libraries,
> and large portions of the language from being used in any consistent
manner
> in dynamically linked libraries.
>
> Although I don't mind considering changes to the runtime to make C++ work
> better I think changes of this nature should be considered a last resort.
> Rather, I would like us to look in depth at each issue and determine the
> following:
>
> "Is it reasonable to require that a conforming implementation of the
> language make this work with existing dynamic linking implementations?"
>
> "If not, is there a change that can be made to the language or library
> definition that would allow this?"
>
> "If not, is this a language or library feature which is isolated enough
that
> it can be deemed to have undefined behavior when used with dynamically
> linked libraries without "crippling" the usefulness of the language for
> these purposes?"
>
> "If not, then is there a change to the loading mechanism that would be
> feasible for a platform provider to make that could enable this."
>
> Because we don't want to mess with "our language" - I fear we are jumping
to
> the conclusion that everything falls into the last category.

Actually, I *do* want to mess with our language. At least, I'm among those
who think the language definition should say something about the semantics
of shared libraries. However, messing with the language has to happen at
both ends: you have to gain implementation experience in addition to
thinking about what the standard should mandate.

-Dave