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

[Sriraman Tallam <tmsriram at google dot com>]

On Sat, May 26, 2012 at 7:06 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sat, May 26, 2012 at 5:23 PM, Sriraman Tallam <tmsriram@google.com> wrote:
>> On Sat, May 26, 2012 at 4:56 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> 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.
>>
>> Right, I agree. But this problem exists right now even if libgcc_s.so
>> is provided with these symbols. Please see example below:
>>
>> Example:
>>
>> dso.c
>> -------
>>
>> int some_func ()
>> {
>> Â return (int) __builtin_cpu_is ("corei7");
>> }
>>
>> Build with gcc driver:
>> $ gcc dso.c -fPIC -shared -o dso.so
>> $ nm dso.so | grep __cpu
>> 0000000000000780 t __cpu_indicator_init
>> 0000000000001e00 b __cpu_model
>>
>> This DSO is getting its own local copy of __cpu_model. This is fine
>> functionally but this is not the behaviour you have in mind.
>>
>> whereas, if I build with g++ driver:
>>
>> $ g++ dso.c -fPIC -shared dso.so
>> $ nm dso.so | grep __cpu
>> Â Â Â Â Â Â Â Â U __cpu_model
>>
>> This is as we would like, __cpu_model is undefined.
>>
>> The difference is that with the gcc driver, the link line is -lgcc
>> -lgcc_s, whereas with the g++ driver -lgcc is not even present!
>>
>> Should I fix the gcc driver instead? This double-standard is not clear to me.
>>
>
> ïhat is because libgcc_s.so is preferred by g++. We can do one
> of 3 things:
>
> 1. Abuse libgcc_eh.a by moving __cpu_model and __cpu_indicator_init
> from libgcc.a to libgcc_eh.a.
> 2. Rename libgcc_eh.a to libgcc_static.a and move __cpu_model and
> __cpu_indicator_init from libgcc.a to libgcc_static.a.
> 3. Add Âlibgcc_static.a and move __cpu_model and __cpu_indicator_ini
> Âfrom libgcc.a to libgcc_static.a. ÂWe treat libgcc_static.a similar to
> libgcc_eh.a.

Any reason why gcc should not be made to prefer libgcc_s.so too like g++?

Thanks for clearing this up. I will take a stab at it.

-Sri.

>
>
> --
> H.J.