On Mon, Aug 22, 2011 at 7:07 AM, Michael Matz <m...@suse.de> wrote: > Hi, > > On Sun, 21 Aug 2011, Richard Guenther wrote: > >> On Sat, Aug 20, 2011 at 11:02 PM, Richard Henderson <r...@redhat.com> wrote: >> > On 08/19/2011 02:04 AM, Richard Guenther wrote: >> >> So make sure that __cpu_indicator initially has a conservative correct >> >> value? I'd still prefer the constructor-in-libgcc option - if only >> >> because >> >> then the compiler-side is much simplified. >> >> >> > >> > Err, I thought __cpu_indicator was a function, not data. >> > >> > I think we need to discuss this more... >> >> 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? -- H.J.
