This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
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