Re: A patch for binutils (Re: the setrlimit changes in glibc 2.1.3)

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

   Date: Thu, 13 Jan 2000 12:46:58 -0800
   From: "H . J . Lu" <hjl@lucon.org>

   On Thu, Jan 13, 2000 at 03:21:29PM -0500, Ian Lance Taylor wrote:
   >    Date: Thu, 13 Jan 2000 11:23:31 -0800
   >    From: "H . J . Lu" <hjl@lucon.org>
   > 
   >    Thanks. Here is a patch for binutils 2.9.5.0.22. Ian, what do you
   >    think?
   > 
   >    Thu Jan 13 11:03:29 2000  H.J. Lu  <hjl@gnu.org>
   > 
   > 	   * elflink.h (elf_link_add_object_symbols): Bound the external
   > 	   references to the default version to the hidden version.
   > 
   > There is something odd about this case.  libtest.so has an external
   > reference to symbol foo in version FOO_1.0.  Why are we looking up
   > foo@@FOO_1.0?  Why aren't we looking up foo@FOO_1.0?  If I understand

   It is because libtest.so is linked against the older libfoo.so,
   libfoo.so.1.0, where the FOO_1.0 of foo is the default. You got the
   reference to foo@@FOO_1.0. The new libfoo.so, libfoo.so.1.1, has
   the FOO_1.1 of foo as default and foo@FOO_1.0 is hidden.

I think you probably understood my point.  Just in case, though, I'll
expand further.

The @ characters do not appear in the dynamic symbol table.  All that
is in the file is the symbol name, the associated version name, and a
flag indicating whether this is a hidden version or not.  The linker
introduces the @ characters as, essentially, a trick to combine the
version name into the symbol name for the linker hash table.

The linker uses a double @ for the default version.  Now that I look
at the code, I'm not sure why it does that (I didn't write this code).
I mean, I see why the linker needs to know whether the symbol is the
default version, but I don't see why it needs to be recorded in the
symbol name itself.  That seems like it's trying to overload the
symbol name unnecessarily.

I know that we permit a source file to use a double @ to indicate the
default version, but that's just a hack to ease life for library
maintainers.  I'm not sure why it should slip into the linker hash
table.

When the linker create a symbol with a double @, it also introduces an
indirection from the symbol of the same name name but with a single @.

Anyhow, this all means that the shared library has no reference to the
literal string "foo@@FOO_1.0".  What it has is a reference to symbol
foo, version FOO_1.0, and the version is not hidden.

So I was asking why we were trying to look up foo@@FOO_1.0.  What we
should have been looking up was symbol foo, version FOO_1.0.  In the
hash table that is represented by foo@FOO_1.0 with a single @.

   > We use the double @ to indicate the default version of a symbol.  But
   > that is only applicable to a definition.  It does not make sense to
   > refer to the default version of a symbol and to simultaneously specify
   > a specific version.  When we do use the double @, we also set up a
   > reference from the unqualified symbol name, and from the symbol name
   > with a single @.

   Please remember a specific version may change from default to hidden.
   However, foo@FOO_1.0 will always be 100 binary compatible with
   foo@@FOO_1.0.

In fact, I believe the two names always name precisely the same
symbol.  It's not a case of compatibility.  foo@FOO_1.0 and
foo@@FOO_1.0 are identical.

   > So I suspect that your patch, which sets up an indirection from
   > foo@@FOO_1.0 to foo@FOO_1.0, is fixing the wrong thing.  We should be
   > asking why there would ever be a reference to foo@@FOO_1.0.
   > 
   > Perhaps the fix is as simple as changing the code to not add a second
   > ELF_VER_CHR if sym.st_shndx is SHN_UNDEF.

   You are right. Here is the new patch. Please ignore my previous one.

Thanks for the patch.

Ian