On Fri, Aug 26, 2011 at 10:45 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Fri, Aug 26, 2011 at 10:37 AM, Sriraman Tallam <tmsri...@google.com> wrote:
>> On Fri, Aug 26, 2011 at 10:24 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> On Fri, Aug 26, 2011 at 10:17 AM, Sriraman Tallam <tmsri...@google.com>
>>> wrote:
>>>> On Fri, Aug 26, 2011 at 10:10 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>> On Fri, Aug 26, 2011 at 10:06 AM, Sriraman Tallam <tmsri...@google.com>
>>>>> wrote:
>>>>>> On Thu, Aug 25, 2011 at 6:02 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>>>> On Thu, Aug 25, 2011 at 5:37 PM, Sriraman Tallam <tmsri...@google.com>
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Thanks for all the comments. I am attaching a new patch
>>>>>>>> incorporating all of the changes mentioned, mainly :
>>>>>>>>
>>>>>>>> 1) Make __cpu_indicator_init a constructor in libgcc and guard to call
>>>>>>>> it only once.
>>>>>>>
>>>>>>> This is unreliable and you don't need 3 symbols from libgcc. You can use
>>>>>>
>>>>>> Do you mean it is unreliable because of the constructor ordering problem?
>>>>>>
>>>>>
>>>>> You do not have total control when __cpu_indicator_init is called.
>>>>
>>>> Like discussed before, for non-ctor functions, which in my opinion is
>>>> the common use case, it works out great because __cpu_indicator_init
>>>> is guaranteed to be called and I save doing an extra check. It is only
>>>>> for other ctors where this is a problem. So other ctors call this
>>>> explicitly. What did I miss?
>>>>
>>>
>>> I have
>>>
>>> static void foo ( void ) __attribute__((constructor));
>>>
>>> static void foo ( void )
>>> {
>>> ...
>>> call bar ();
>>> ...
>>> }
>>>
>>> in my application. bar () uses those cpu specific functions.
>>> foo () is called before __cpu_indicator_init. Since IFUNC
>>> returns the cpu specific function address only for the
>>> first call, the proper cpu specific functions will never be used.
>>
>> Please correct me if I am wrong since I did not follow the IFUNC part
>> you mentioned. However, it looks like this could be solved with
>> adding an explicit call to __cpu_indicator_init from within the ctor
>> foo. To me, it seems like the pain of adding this call explicitly in
>> other ctors is worth it because it works cleanly for non-ctors.
>>
>> static void foo ( void ) __attribute__((constructor));
>>
>> static void foo ( void )
>> {
>> ...
>> __cpu_indicator_init ();
>> call bar ();
>> ...
>> }
>>
>> Will this work?
>>
>>
>
> Do I have to do that in every constructor, including
> C++ global constructors? It is ridiculous.
It seems like libgcc is on the link line after user code in the
command-line and so __cpu_indicator_init should fire first, both when
statically and dynamically linked.
Example:
foo.cc:
int __attribute__ ((constructor))
foo ()
{
return 0;
}
However, with something like this :
g++ -Wl,--u,__cpu_indicator_init -lgcc foo.cc
foo gets called ahead of __cpu_indicator_init. For these abnormal link
usages, call it explicitly. So, can you please give me a common use
case where __cpu_inidicator_init will get called after a constructor.
Thanks,
-Sri.
>
> --
> H.J.
>
