[Bug gold/18703] Symbol version and Version script incompatibility with BFD ld

[ccoutant at gmail dot com]

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
<address@hidden> 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
> <address@hidden> 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
>> address@hidden (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.