Bug 12261 - gold fails to link symbols explicitly defined in base-version
Summary: gold fails to link symbols explicitly defined in base-version
Status: WAITING
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.22
: P2 normal
Target Milestone: ---
Assignee: Cary Coutant
URL:
Keywords:
: 12262 (view as bug list)
Depends on: 12977 18703
Blocks:
  Show dependency treegraph
 
Reported: 2010-11-24 01:20 UTC by Diego Elio Pettenò
Modified: 2015-09-02 00:46 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Patch to solve the problem above (1.05 KB, patch)
2010-11-24 01:23 UTC, Diego Elio Pettenò
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Diego Elio Pettenò 2010-11-24 01:20:35 UTC
The binutils manual for ld suggests using this syntax to define a symbol explicitly in base-version:

__asm__(".symver original_foo,foo@");
__asm__(".symver new_foo,foo@@VERS2");

but code compiled with this syntax is rejected by gold as the version "" is undefined.

I'm attaching a patch to solve the issue, which ensures that the base version is registered for the "" version.

Thanks,
Diego
Comment 1 Diego Elio Pettenò 2010-11-24 01:22:19 UTC
*** Bug 12262 has been marked as a duplicate of this bug. ***
Comment 2 Diego Elio Pettenò 2010-11-24 01:23:18 UTC
Created attachment 5138 [details]
Patch to solve the problem above
Comment 3 Ian Lance Taylor 2010-11-24 03:28:08 UTC
Thanks for the patch.  I've been troubled by this for a while, because defining a symbol in the base version doesn't reliably cause the glibc dynamic linker to select it when linking against a symbol with no version information.  This thread has some more information: http://sourceforge.net/mailarchive/forum.php?thread_name=m3wrq48tso.fsf%40pepe.airs.com&forum_name=fuse-devel

I'm not sure what the right choice is here.
Comment 4 Diego Elio Pettenò 2010-11-24 06:46:57 UTC
Whether there is or not a bug in the glibc loader, is not something that should matter here, IMHO.

We have a documented use case that, ELF side, works exactly as intended, and a software that tries to use the documented syntax but fails. We also have Chrom(e|ium)OS going toward a hack (creating an UNVERSIONED version to attach to those symbols) just to be able to compile it.

From my point of view, the right choice on the link editor side is to emit the correct ELF file (rather than stop on a corner case), and then report/track down the issue on ld.so side to ensure that it links as intended. This avoids having nasty hacks in place for fuse, and behaves as the documentation says it should.
Comment 5 Raymes Khoury 2010-11-24 17:06:04 UTC
This seems reasonable to me. The FUSE developers are unwilling to accept our workaround patch meaning we (ChromiumOS) are currently forced to maintain a local patch or use GNU ld.
Comment 6 Raymes Khoury 2011-01-19 00:13:04 UTC
Hi Ian,

Could we have an update on this? It would be nice to be able to push this patch.

Thanks,
Raymes
Comment 7 Ian Lance Taylor 2011-02-27 18:12:22 UTC
The key question here is what the glibc developers believe the correct behaviour should be.  If glibc is currently acting as intended, then GNU ld should change (and fuse should change too).  If glibc is in error, then gold should change to match the GNU ld behaviour.  Right now, as far as I can tell, gold is protecting people from relying on unpredictable glibc behaviour.
Comment 8 Ian Lance Taylor 2011-02-27 21:31:18 UTC
I raised the issue on the libc-alpha mailing list:

http://sourceware.org/ml/libc-alpha/2011-02/msg00154.html
Comment 9 Ian Lance Taylor 2011-07-09 05:33:26 UTC
No response on libc mailing list.  Filed a bug report: http://sourceware.org/bugzilla/show_bug.cgi?id=12977
Comment 10 Cary Coutant 2015-09-02 00:46:55 UTC
Fixed by PR 18703. Gold will accept the base version definition, but the issue Ian raised with glibc is still open.