|Summary:||gold fails to link symbols explicitly defined in base-version|
|Product:||binutils||Reporter:||Diego Elio Pettenò <flameeyes>|
|Component:||gold||Assignee:||Cary Coutant <ccoutant>|
|Severity:||normal||CC:||ccoutant, devurandom, raymes.khoury|
|Bug Depends on:||12977, 18703|
|Attachments:||Patch to solve the problem above|
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.
Comment 11 Alan Modra 2022-07-28 22:34:49 UTC