Re: User directed Function Multiversioning via Function Overloading (issue5752064)

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam <tmsriram@google.com> wrote:
> On Fri, May 25, 2012 at 10:05 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam <tmsriram@google.com> wrote:
>>>
>>> On May 25, 2012 7:15 PM, "H.J. Lu" <hjl.tools@gmail.com> wrote:
>>>>
>>>>
>>>> On May 25, 2012 6:54 PM, "Sriraman Tallam" <tmsriram@google.com> wrote:
>>>> >
>>>> >
>>>> > >>
>>>> > >> On Fri, May 25, 2012 at 5:0 > > BTW, I noticed:
>>>>
>>>> > >
>>>> > > [hjl@gnu-6 pr14170]$ readelf -sW libgcc.a | grep __cpu_model
>>>> > > ? ?20: 0000000000000010 ? ?16 OBJECT ?GLOBAL HIDDEN ? COM __cpu_model
>>>> > > [hjl@gnu-6 pr14170]$ readelf -sW libgcc_s.so | grep __cpu_model
>>>> > > ? ?82: 0000000000214ff0 ? ?16 OBJECT ?GLOBAL DEFAULT ? 24
>>>> > > __cpu_model@@GCC_4.8.0
>>>> > > ? 310: 0000000000214ff0 ? ?16 OBJECT ?GLOBAL DEFAULT ? 24 __cpu_model
>>>> > > [hjl@gnu-6 pr14170]$
>>>> > >
>>>> > > Why is __cpu_model in both libgcc.a and libgcc_s.o?
>>>> >
>>>> > How do I disallow this in libgcc_s.so? Looks like t-cpuinfo file is
>>>> > wrong but I cannot figure out the fix.
>>>> >
>>>> Why don't you want it in libgcc_s.so?
>>>
>>> I thought libgcc.a is always linked in for static and dynamic builds. So
>>> having it in libgcc_s.so is redundant.
>>>
>>
>> [hjl@gnu-6 pr14170]$ readelf -sW libgcc.a | grep _cpu_
>> ? ?20: 0000000000000010 ? ?16 OBJECT ?GLOBAL HIDDEN ? COM __cpu_model
>> ? ?21: 0000000000000110 ? 612 FUNC ? ?GLOBAL HIDDEN ? ? 4 __cpu_indicator_init
>> [hjl@gnu-6 pr14170]$ readelf -sW libgcc_s.so.1 | grep _cpu_
>> ? ?82: 0000000000214ff0 ? ?16 OBJECT ?GLOBAL DEFAULT ? 24
>> __cpu_model@@GCC_4.8.0
>> ? 223: 0000000000002b60 ? 560 FUNC ? ?LOCAL ?DEFAULT ? 11 __cpu_indicator_init
>> ? 310: 0000000000214ff0 ? ?16 OBJECT ?GLOBAL DEFAULT ? 24 __cpu_model
>> [hjl@gnu-6 pr14170]$
>>
>> I think there should be only one copy of __cpu_model in the process.
>> It should be in libgcc_s.so. Why isn't ?__cpu_indicator_init exported
>> from libgcc_s.so?
>
> Ok, I am elaborating so that I understand the issue clearly.
>
> The dynamic symbol table of libgcc_s.so:
>
> $ objdump -T libgcc_s.so | grep __cpu
>
> 0000000000015fd0 g ? ?DO .bss ? 0000000000000010 ?GCC_4.8.0 ? __cpu_model
>
> It only has __cpu_model, not __cpu_indicator_init just like you
> pointed out. I will fix this by adding a versioned symbol of
> __cpu_indicator_init to the *.ver files.

That will be great.

> Do you see any other issues here? I dont get the duplicate entries
> part you are referring to. The static symbol table also contains
> references to __cpu_model and __cpu_indicator_init, but that is
> expected right?

Duplication comes from static and dynamic symbol tables.

> In libgcc.a:
>
> readelf -sWt /g/tmsriram/GCC_trunk_svn_mv_fe_at_nfs/native_builds/bld1/install/lib/gcc/x86_64-unknown-linux-gnu/libgcc.a
> | grep __cpu
>
> ? 20: 0000000000000010 ? ?16 OBJECT ?GLOBAL HIDDEN ?COM __cpu_model
> ? ?21: 0000000000000110 ? 612 FUNC ? ?GLOBAL HIDDEN ? ?4 __cpu_indicator_init
>
> libgcc.a has __cpu_model and __cpu_indicator_init as GLOBAL syms with
> HIDDEN visibility. Is this an issue? Is this not needed for static
> linking?
>
> Further thoughts:
>
> * It looks like libgcc.a is always linked for both static and dynamic
> links. It occurred to me when you brought this up. So, I thought why
> not exclude the symbols from libgcc_s.so! Is there any problem here?
>

You don't want one copy of those 2 symbols in each DSO where
they are used.

-- 
H.J.