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

[Sean Parent <sparent at adobe dot com>]

[Reading this thread gets confusing about when people are discussing
explicitly loaded (and unloaded) libraries vs. libraries which are
dynamically linked - the issues are very different so let's try to be clear
about what case is being discussed in which message.]

I'm discussing in this message the case of dynamic linking.

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

[A small issue here - let's not introduce "shared" into the vocabulary.
Whether or not a library is shared by other processes when it is dynamically
linked usually has no relevance - and when it is relevant, for example in a
system that allows for an instantiation of the library to be shared across
processes, the added complexity only complicates this discussion.]

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

This opens the question - is it necessary to force a new model for loading
libraries to get reasonable semantics for C++ dynamic linking? 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.
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.
 
> 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.

Sean

-- 
Sean Parent
Sr. Computer Scientist II
Advanced Technology Group
Adobe Systems Incorporated
sparent@adobe.com