Re: A patch for default version and archive

[Ian Lance Taylor <ian at zembu dot com>]

   Date: Tue, 14 Nov 2000 11:35:23 -0800
   From: "H . J . Lu" <hjl@valinux.com>

   Ok, let me try it again. Here is my take. I know Ulrich may not agree
   with me. To me, symbol versioning provides a way to reference and
   define a symbol with a version. For a reference to the symbol "foo"
   and version "ver1", it can only be resolved with the definition of
   the symbol "foo" and version "ver1". There are 2 different versioned
   definitions:

   1. The normal versioned definition. The normal versioned definition of
   the symbol "foo" and version "ver1" can only resolve the reference
   to the symbol "foo" and version "ver1".
   2. The default versioned definition. The default versioned definition
   of the symbol "foo" and version "ver1" can resolve the reference
   to the symbol "foo" and version "ver1" as well as the reference to
   the symbol "foo" without any version. It can also be overriden by
   another default versioned definition or a definition without version.

   The symbol resolution should follow the normal ELF linker rule.

This description makes it seem as though the symbol version is really
just part of the name (which is indeed approximately how we implement
them).  We could implement this by saying a symbol "foo" with version
"ver1" is really a symbol named "foo-ver1".  The default versioned
definition of symbol "foo" with version "ver1" is simply two symbols
which are aliased to the same value: "foo-ver1" and "foo".

However, thinking about it, I see that you have glossed over some
issues in your point 2.  You say that the default symbol can be
overridden by a definition without a version.  Let us say that we have
a reference to symbol (1) "foo" with version "ver1", and we have a
reference to (2) "foo".  Let us say that in a shared library we have a
definition of (3) "foo" with default version "ver1".  References (1)
and (2) will both resolve to definition (3), right?  But now lets say
that in a regular object file we have a definition of (4) "foo".  Now,
according to your description, (4) overrides (3).  Clearly (2) should
resolve to (4).  Should (1) also resolve to (4)?  If (1) does resolve
to (4), that implies that a default version (3) can somehow loan its
version string to a symbol (4) with the same name but no version.
That seems strange.

We must also consider the case of (1), (2), and (3) as above, but now
in a regular object file we have (5) "foo" with version "ver1" but
where (5) is not the default version.  Presumably (1) should resolve
to (5).  Should (2) also resolve to (5)?  If (2) does resolve to (5),
that implies that a default version (3) can somehow loan its default
character to a symbol (5) with the same name and version, but which is
not the default.  That seems strange.

Although these cases are more obvious when we consider regular files,
I believe they can also occur when multiple shared libraries define
the same symbols.  How does the Solaris linker behave with these
cases?  Are they covered in their documentation?

One way to resolve these confusions might be to ban overriding of
symbols with default versions--to treat that case as a multiple
definition error.  I don't know what that would break.

Another way to resolve the confusions would be to ban references to
symbols with versions.  It's very unclear to me why references to
symbols with versions is a desirable feature.  Ulrich's write up bans
them, though the assembler permits them.  But what useful feature do
they provide?  Why should we permit them?  Are they used today?

Ian