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

[martin at v dot loewis dot de (Martin v. Loewis)]

"David Abrahams" <david.abrahams@rcn.com> writes:

> Don't change anything just for me. A change should be made because it's the
> right thing to do. 

It's not obvious what the right thing to do is, here. Changing
typeinfo comparison will lose performance. It is not clear that
"traditional" (i.e. most) applications, which just compile and link a
"program" should be penalized to support more exotic applications.

That's a difficult judgement, and not one I'm willing to make.

> Again, of course. You seem to be operating on the assumption that
> users of shared libraries will expect them to be semantically
> equivalent to good-ol'-static linking under all circumstances, and
> that if we can't make them equivalent we shouldn't give any
> guarantees at all. Of course, nobody but the most naive users have
> that expectation.

You might be surprised how many users have that expectation. As you
know, Ralf originally was linking a static libboost, and it never
occurred to him that something might be wrong in the build process.

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

> Yes, we can make shared libs act like static libs when they're
> linked in the usual way, but other arrangements are quite common,
> and users have a mental model for those as well. It's not clear that
> the model corresponds with reality, of course, but it's worth
> supporting well-defined semantics when possible.

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.

> 1. For each symbol, there is an undirected graph which determines how it is
> shared.
> 2. Nodes of the graph correspond to shared libraries. There is also a node
> for the sole executable.
> 3. At each boundary between nodes where there is global symbol sharing,
> either via explicit linking, or via dlopen with RTLD_GLOBAL, an edge is
> formed between nodes in a symbol's graph iff the symbol is used (defined or
> unresolved) in BOTH nodes
> 4. A symbol's definition is shared between nodes A and B iff A is reachable
> from B in that symbol's graph. Note that this is only true if there is a
> continuous chain of global sharing between A and B, and all intermediate
> nodes use the symbol as well.

That item 4 is in violation of the ELF spec. If both A and B define
the same symbol, and if the symbol is weak, and if A is reachable from
B, then the dynamic linker shall chose the definition of in B, not the
definition in A.

This is necessary to allow executables to override the definition in a
shared library, e.g. for replacement functions.

Regards,
Martin