bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: tmsriram at google dot com
Subject: [Bug gold/18703] Symbol version and Version script incompatibility with BFD ld
Date: Wed, 22 Jul 2015 18:09:50 +0000

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
<address@hidden> 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 address@hidden  The difference
>> is NAME2@@NODENAME will also be used to resolve references to NAME2 by
>> the linker.
>>
>> Linker shouldn't use address@hidden to resolve references to foo.
>
> Yes, I understand that much. The example given uses:
>
>    .symver foo, address@hidden
>
> 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 address@hidden
>
> 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, address@hidden" and
> rename "foo" to "orig_foo", I get the following in the dynamic symbol
> table:
>
>      6: 0000000000000725    11 FUNC    GLOBAL DEFAULT   12 address@hidden
>      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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]