On Sat, May 26, 2012 at 4:56 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Sat, May 26, 2012 at 3:34 PM, Sriraman Tallam <tmsri...@google.com> wrote:
>> On Fri, May 25, 2012 at 10:05 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> On Fri, May 25, 2012 at 8:38 PM, Sriraman Tallam <tmsri...@google.com>
>>> wrote:
>>>>
>>>> On May 25, 2012 7:15 PM, "H.J. Lu" <hjl.to...@gmail.com> wrote:
>>>>>
>>>>>
>>>>> On May 25, 2012 6:54 PM, "Sriraman Tallam" <tmsri...@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.
Thanks,
-Sri.
>
> --
> H.J.
