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. -- H.J.
