This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A patch for default version and archive


   Date: Wed, 15 Nov 2000 11:09:36 -0800
   From: "H . J . Lu" <hjl@valinux.com>

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

I know that.  But I think that is just an implementation detail.  It
doesn't affect the semantics of the symbols.

   > 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

Those are references to versioned symbols within a shared library,
aren't they?  I see them only in the ordinary symbol table, not in the
dynamic symbol table.  In a shared library, the dynamic symbol table
is what counts.  It may be a bug in the program linker that it emits
versioned symbol references in the ordinary symbol table for a shared
library.

   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.

I wouldn't want to make any restrictions for system vs. non-system
libraries, but it might be correct to make restrictions for shared
objects vs. object files.

But I should say again that I don't know what the right solution is
here.  I'm not advocating a particular point of view.  I'm just
looking for one that makes sense to me.

Ian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]