https://sourceware.org/bugzilla/show_bug.cgi?id=18703
--- Comment #3 from Cary Coutant <ccoutant at gmail dot com> --- Sorry, I need more context than that. You've said that the symbol is not versioned, but in fact it is. The only differences between the two linkers that I see are: (1) The name that appears in the linker symbol table, which shouldn't matter to the loader at all. If this is causing a problem, can you point to the section in the linker manual that describes the correct behavior? I don't think gold was designed with the intent of propagating @-style version information into the output binary. We only use the version sections, and, as far as I know, the dynamic loader only uses version sections. (2) Gold defines the symbol as a default version, while Gnu ld doesn't. If this is the problem, I'll need to understand what the proper logic is for determining whether a symbol should be marked as the default version. You said this affects building libgcc_s.so in trunk, but you haven't said what is actually failing. -cary On Tue, Jul 21, 2015 at 4:51 PM, tmsriram at google dot com <sourceware-bugzi...@sourceware.org> wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=18703 > > --- Comment #2 from Sriraman Tallam <tmsriram at google dot com> --- > On Tue, Jul 21, 2015 at 11:03 AM, ccoutant at gmail dot com > <sourceware-bugzi...@sourceware.org> wrote: >> https://sourceware.org/bugzilla/show_bug.cgi?id=18703 >> >> --- Comment #1 from Cary Coutant <ccoutant at gmail dot com> --- >> You're looking at the linker symbol table with nm. (And nm does not show >> versioning information from the .gnu.version* sections.) >> >> When I build this with gold, readelf -Vs shows: >> >> Symbol table '.dynsym' contains 13 entries: >> Num: Value Size Type Bind Vis Ndx Name >> 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND >> 1: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__ >> 2: 0000000000000000 0 NOTYPE WEAK DEFAULT UND >> _ITM_deregisterTMCloneTab >> 3: 0000000000000000 0 FUNC WEAK DEFAULT UND >> __cxa_finalize@GLIBC_2.2.5 (3) >> 4: 0000000000000000 0 NOTYPE WEAK DEFAULT UND >> _ITM_registerTMCloneTable >> 5: 0000000000000000 0 NOTYPE WEAK DEFAULT UND >> _Jv_RegisterClasses >> 6: 00000000000006f5 11 FUNC GLOBAL DEFAULT 12 foo@@VERS_1.1 >> 7: 0000000000002018 0 NOTYPE GLOBAL DEFAULT ABS _edata >> 8: 0000000000002019 0 NOTYPE GLOBAL DEFAULT ABS _end >> 9: 00000000000005c0 0 FUNC GLOBAL DEFAULT 10 _init >> 10: 0000000000002018 0 NOTYPE GLOBAL DEFAULT ABS __bss_start >> 11: 0000000000000700 0 FUNC GLOBAL DEFAULT 13 _fini >> 12: 0000000000000000 0 OBJECT GLOBAL DEFAULT ABS VERS_1.1 >> >> ... >> >> Version symbols section '.gnu.version' contains 13 entries: >> Addr: 0000000000000458 Offset: 0x000458 Link: 2 (.dynsym) >> 000: 0 (*local*) 0 (*local*) 0 (*local*) 3 >> (GLIBC_2.2.5) >> 004: 0 (*local*) 0 (*local*) 2 (VERS_1.1) 1 (*global*) >> 008: 1 (*global*) 1 (*global*) 1 (*global*) 1 (*global*) >> 00c: 2 (VERS_1.1) >> >> Version definition section '.gnu.version_d' contains 2 entries: >> Addr: 0x0000000000000474 Offset: 0x000474 Link: 3 (.dynstr) 000000: >> Rev: 1 >> Flags: BASE Index: 1 Cnt: 1 Name: ver1.so >> 0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: VERS_1.1 >> >> Version needs section '.gnu.version_r' contains 1 entries: >> Addr: 0x00000000000004ac Offset: 0x0004ac Link: 3 (.dynstr) >> 000000: Version: 1 File: libc.so.6 Cnt: 1 >> 0x0010: Name: GLIBC_2.2.5 Flags: none Version: 3 >> >> I think this is working as intended, although comparing with Gnu ld output, I >> see that gold defines it as a default version ("@@") where Gnu ld does not. >> I'm >> not sure what the logic ought to be for that. Without the __asm__ in the .c >> file, Gnu ld also makes it a default version. > > Some context: > > https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00878.html > > This was used to hide symbols __cpu_indicator_init and __cpu_model > defined in libgcc_s.so so that this symbol is always obtained from > libgcc.a. Now, this works with GNU ld and not with gold. Isnt this an > incompatibility. If this is not well defined, is there another well > defined way of achieving the same result? > > Thanks > Sri > > >> >> -- >> You are receiving this mail because: >> You reported the bug. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > You are the assignee for the bug. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
