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