User directed Function Multiversioning via Function Overloading (issue5752064)

[H.J. Lu]

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.


-- 
H.J.