User directed Function Multiversioning via Function Overloading (issue5752064)

[H.J. Lu]

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?

-- 
H.J.