Re: A patch for default version and archive

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

On Thu, Nov 16, 2000 at 10:30:18AM -0800, Ian Lance Taylor wrote:
>    Date: Wed, 15 Nov 2000 17:05:29 -0800
>    From: "H . J . Lu" <hjl@valinux.com>
> 
>    > 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.
> 
>    I am enclosing a testcase here. For this one, (1) resolves to (4). It
>    is not entirely unexpected. We can say
> 
>    1. (1) resolves to (3).
>    2. Since (3) is the default definition, it can be overriden by (4).
> 
>    Think about it, "a default version (3) can somehow loan its version
>    string to a symbol (4) with the same name but no version." does make
>    sense since a default version can resolve an unversioned reference
>    and can be overriden by an unversioned definition.
> 
> I'm finding it really hard to buy that.  What this amounts to is that
> "foo" version "ver1" is being resolved to "foo".  That wouldn't
> normally happen.  It is only happening because of the presence of

Why not? If the definition of "foo" version "ver1" happens to be the
default definition, it can be overriden by "foo".

> another object in the link, which may wind up not even being used,
> which happens to define the symbol "foo" with a default version of
> "ver1".  That is really strange behaviour--hard to explain and hard to
> understand.  When would that behaviour ever be useful?

Say you want to override "open" in libc.so:

# objdump --dynamic-sym /lib/libc.so.6 | grep GLIBC| grep " open$"
000d8d80  w   DF .text  00000040  GLIBC_2.0   open
# objdump --dynamic-sym /usr/lib/lib*.so | grep GLIBC | grep " open$"
.....
00000000      DF *UND*  0000003d  GLIBC_2.0   open

As you can see, many DSOs in /usr/lib have "open" bound to version
"GLIBC_2.0". Since GLIBC_2.0 is the default version, by providing your
own implementation of "open", all refereneces to "open" version
"GLIBC_2.0" will be resolved to your "open" without version. That is
exactly what happens if there is no symbol versioning.

> 
>    > 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 is a multiple definition error today :-).
> 
> But you said earlier ``Glibc overrides the default version between
> ld.so and libc.so, libpthread and libc.so.''  Which is it?
> 

It is a different issue. See

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=20997

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