bug-binutils
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]