[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug gold/13521] New: ld.gold prefers unversioned symbol over default ve
From: |
jrnieder at gmail dot com |
Subject: |
[Bug gold/13521] New: ld.gold prefers unversioned symbol over default version |
Date: |
Tue, 20 Dec 2011 07:13:00 +0000 |
http://sourceware.org/bugzilla/show_bug.cgi?id=13521
Bug #: 13521
Summary: ld.gold prefers unversioned symbol over default
version
Product: binutils
Version: 2.23 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
AssignedTo: address@hidden
ReportedBy: address@hidden
CC: address@hidden
Classification: Unclassified
Created attachment 6119
--> http://sourceware.org/bugzilla/attachment.cgi?id=6119
simple object with reference to lzma_code before linking
The ld manual (section VERSION) explains how to allow multiple versions of the
same function to appear in a given shared library[1].
Debian liblzma5 5.1.1alpha+20110809-3 does that. It provides two versions of
the lzma_code function --- an unversioned compatibility symbol and a versioned
symbol:
| $ eu-readelf -s /usr/lib/x86_64-linux-gnu/liblzma.so.5.0.0 | grep lzma_code
| 32: 00000000000030f0 142 FUNC GLOBAL DEFAULT 13 lzma_code
| 33: 0000000000003020 202 FUNC GLOBAL DEFAULT 13
lzma_code@@XZ_5.0
When I link to the library using ld.bfd, the versioned symbol is preferred, as
I'd expect[2]:
| $ ld.bfd -o test.bfd test.o -llzma
| ld.bfd: warning: cannot find entry symbol _start; defaulting to
0000000000400270
| $ eu-readelf -s test.bfd | grep lzma_code
| 1: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF
address@hidden (2)
| 17: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF
lzma_code@@XZ_5.0
By contrast, ld.gold seems to prefer the unversioned symbol.
| $ ld.gold -o test.gold test.o -llzma
| $ eu-readelf -s test.gold | grep lzma_code
| 1: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF lzma_code
| 5: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF lzma_code
Reproducible with binutils 2.22 and with a current snapshot of HEAD (3d38152c,
2011-12-19). Known problem? Any hints for tracking it down?
[1] “The second GNU extension is to allow multiple versions of the same
function to appear in a given shared library. In this way you can make an
incompatible change to an interface without increasing the major version number
of the shared library, while still allowing applications linked against the old
interface to continue to function.
“To do this, you must use multiple `.symver' directives in the source file.
Here is an example:
__asm__(".symver original_foo,foo@");
__asm__(".symver old_foo,address@hidden");
__asm__(".symver old_foo1,address@hidden");
__asm__(".symver new_foo,foo@@VERS_2.0");
“In this example, `foo@' represents the symbol `foo' bound to the unspecified
base version of the symbol. The source file that contains this example would
define 4 C functions: `original_foo', `old_foo', `old_foo1', and `new_foo'.”
[2] “When you have multiple definitions of a given symbol, there needs to be
some way to specify a default version to which external references to this
symbol will be bound. You can do this with the `foo@@VERS_2.0' type of
`.symver' directive. You can only declare one version of a symbol as the
default in this manner; otherwise you would effectively have multiple
definitions of the same symbol.”
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
- [Bug gold/13521] New: ld.gold prefers unversioned symbol over default version,
jrnieder at gmail dot com <=