Re: A patch for default version and archive

["H . J . Lu" <hjl at valinux dot com>]

On Wed, Nov 15, 2000 at 10:04:58AM -0800, Ian Lance Taylor wrote:
>    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".

It is not entirely accurate. The symbol versioning can be introduced
via the linker script. In that case, the default versioned definition
is done via the .gnu.version* sections.

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

No, (1) shouldn't be resolved to (4). That is a good point. I will
check it out.

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

Like it or not, even if we don't do explicit versioned references
today, it is here thanks to shared libraries. Just do

# nm /usr/lib/lib*.so | grep GLIBC

You will see what I mean. Both the dyanmic linker and static linker
have to deal with it. See

2000-02-22  H.J. Lu  <hjl@gnu.org>

	* elflink.h (elf_link_add_object_symbols): If a version symbol is
	not defined, don't add a second ELF_VER_CHR.

Banning the versioned references in asm code doesn't solve the problem.
The problem you described is nothing new. It can/will happen if we are
not careful. I guess we have to document how we should use it. Since
the symbol versioning was motivated by libc. We can just say the symbol
versioning can only be used by the system libraries, similar to the
weak symbol.

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

It won't work. Glibc overrides the default version between ld.so and
libc.so, libpthread and libc.so.

> 
> 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?
> 

My glibc proposal will address it. Here is from Eric's writeup:

----
        Note that the VERS_2.0 version is bound with the foo@@VERS_2.0
(it uses a @@ rather than an @).  This serves to signify that the
symbol is the default version of the function to which external
references are bound if they don't explicitly specify a version 
number.  In general, the version specification tags won't appear in
any header files, and will only go in the library sources themselves,
so external references will tend to be just for 'foo'.  If you are 
absolutely sure that you need to bind to a non-default interface, then
you will have to fully specify the version you want in the place where
you reference it.  An example of how you do this is not yet available.
----

I put the full text at

http://ftp.valinux.com/pub/support/hjl/glibc/compat/GNUvers.txt

It seems that Eric was not sure how the versioned reference could be
used. But certainly he didn't ban it. My glibc proposal does want to
bind to a known interface, which may be implemented as a non-default
interface.

Ian, I will make 2 testcases you brought up to see what they do.

Thanks.


-- 
H.J. Lu (hjl@valinux.com)