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.
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?
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?
Example:
file:test.c
int main ()
{
return (int) __builtin_cpu_is ("corei7");
}
Case I : Use gcc to build dynamic
$ gcc test.c -Wl,-y,__cpu_model
libgcc.a(cpuinfo.o): reference to __cpu_model
libgcc_s.so: definition of __cpu_model
Case II: Use g++ to build dynamic
$ g++ test.c -Wl,-y,__cpu_model
fe1.o: reference to __cpu_model
libgcc_s.so: definition of __cpu_model
Case III: Use gcc to link static
$ gcc test.c -Wl,-y,__cpu_model -static
fe1.o: reference to __cpu_model
libgcc.a(cpuinfo.o): reference to __cpu_model
Please note that in all 3 cases, libgcc.a was linked in. Hence,
removing these symbols from the dynamic symbol table of libgcc_s.so
should have no issues.
Thanks,
-Sri.
>
> --
> H.J.
