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

[Sriraman Tallam <tmsriram at google dot com>]

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.

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.