On Mon, Aug 22, 2011 at 10:48 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Mon, Aug 22, 2011 at 1:46 PM, Richard Guenther
> <richard.guent...@gmail.com> wrote:
>> On Mon, Aug 22, 2011 at 10:39 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>> On Mon, Aug 22, 2011 at 1:34 PM, Richard Guenther
>>> <richard.guent...@gmail.com> wrote:
>>>> On Mon, Aug 22, 2011 at 6:02 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
>>>>> On Mon, Aug 22, 2011 at 8:56 AM, Michael Matz <m...@suse.de> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, 22 Aug 2011, H.J. Lu wrote:
>>>>>>
>>>>>>> >> Oh, I thought it was data initialized by the constructor ...
>>>>>>> >
>>>>>>> > Sriramans patch right now has a function __cpu_indicator_init which is
>>>>>>> > called from (adhoc constructed) ctors and that initializes variables
>>>>>>> > __cpu_model and __cpu_features ;-) There's no __cpu_indicator symbol
>>>>>>> > :)
>>>>>>> >
>>>>>>> > I think the whole initializer function and the associated data blobs
>>>>>>> > have
>>>>>>> > to sit in static libgcc and be hidden. By that all shared modules
>>>>>>> > will have their own copies of the model and features (and the
>>>>>>> > initializer
>>>>>>> > function) so there won't be issues with copy relocs, or cross shared
>>>>>>> > lib
>>>>>>> > calls while relocating the modules. Dynamically they will contain the
>>>>>>> > same data always, but it's not many bytes, and only modules making
>>>>>>> > use of
>>>>>>> > this facility will pay it.
>>>>>>> >
>>>>>>> > The initializer function has to be callable from pre-.init contexts,
>>>>>>> > e.g.
>>>>>>> > ifunc dispatchers. And to make life easier there should be one ctor
>>>>>>> > function calling this initializer function too, so that normal code
>>>>>>> > can
>>>>>>> > rely on it being already called saving one check.
>>>>>>> >
>>>>>>>
>>>>>>> It sounds more complicated than necessary. Why not just do it
>>>>>>> on demand like glibc does?
>>>>>>
>>>>>> Ehm, the only difference would be to not have a ctor in libgcc that looks
>>>>>> like so:
>>>>>>
>>>>>> void __attribute__((constructor)) bla(void)
>>>>>> {
>>>>>> __cpu_indicator_init ();
>>>>>> }
>>>>>>
>>>>>> I don't see any complication.?
>>>>>>
>>>>>
>>>>> Order of constructors. A constructor may call functions
>>>>> which use __cpu_indicator.
>>>>
>>>> As I said - make __cpu_indicator have a conservative
>>>> default value (zero). It is irrelevant if constructors that
>>>> run before initializing __cpu_indicator run with the
>>>> default CPU capabilities.
>>>>
>>>
>>> If IFUNC is used, this just disables IFUNC for those functions
>>> called with the conservative default value since they are only
>>> resolved once.
>>
>> Huh, well. So what happens if you use __cpu_indicator from the
>> IFUNC selector function!? Honestly, if we care about these
>> corner-cases why not make __cpu_indicator a hidden function
>> instead.
>>
>> IMHO IFUNC selectors should simply do
>>
>> if (!__cpu_indicator)
>> __cpu_indicator_init ();
>>
>
> Isn't it what I said before?
Not in the quoted parts. What I don't want is a constructor in each module.
Keep a single one in libgcc and document the __cpu_indicator usage
restrictions.
Richard.
> --
> H.J.
>
