https://sourceware.org/bugzilla/show_bug.cgi?id=18703
--- Comment #15 from Sriraman Tallam <tmsriram at google dot com> ---
On Tue, Jul 21, 2015 at 5:35 PM, ccoutant at gmail dot com
<sourceware-bugzi...@sourceware.org> wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=18703
>
> --- Comment #6 from Cary Coutant <ccoutant at gmail dot com> ---
>>    Another usage of the '.symver' directive is:
>>      .symver NAME, NAME2@@NODENAME
>>    In this case, the symbol NAME must exist and be defined within the
>> file being assembled.  It is similar to NAME2@NODENAME.  The difference
>> is NAME2@@NODENAME will also be used to resolve references to NAME2 by
>> the linker.
>>
>> Linker shouldn't use foo@VERS_1.1 to resolve references to foo.
>
> Yes, I understand that much. The example given uses:
>
>    .symver foo, foo@VERS_1.1
>
> where the original symbol and the versioned symbol both have the same
> name. This produces two symbols in the .o file named "foo":
>
> 0000000000000000 T foo
> 0000000000000000 T foo@VERS_1.1
>
> With the version script, gold sees the first of those (plain "foo")
> and makes it the default version (as, I think, it should). The second
> one is just seen as a second declaration, but it's already been marked
> the default.
>
> If I change Sri's example to use ".symver orig_foo, foo@VERS_1.1" and
> rename "foo" to "orig_foo", I get the following in the dynamic symbol
> table:
>
>      6: 0000000000000725    11 FUNC    GLOBAL DEFAULT   12 foo@VERS_1.1
>      7: 0000000000000725    11 FUNC    GLOBAL DEFAULT   12 orig_foo
>
> If it's the "@@" vs. "@" that's causing the problem, then there's your fix.

H.J. :  Can we use Cary's idea to fix libgcc/config/i386/cpuinfo.c to
make libgcc_s.so.1 do the right thing with gold too until this issue
is resolved in some manner?

Thanks
Sri


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

_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils

Reply via email to