Re: [PATCHv4 0/2] tunables for glibc

[Siddhesh Poyarekar <siddhesh at sourceware dot org>]

On Wednesday 07 September 2016 08:14 PM, H.J. Lu wrote:
>> However a cleaner approach seems to me to be to keep the cpu features
>> stuff separate from the overriding and then modify the ifunc resolvers
>> to use the overrides if necessary.  That is, let the cpu features show
>> what the cpu is actually capable of and have a separate overriding
>> structure that is initialized later (via __init_tunables or before ifunc
>> resolution) and used when necessary, i.e. not used for AT_SECURE
>> executables or any other condition that may arise in future.
> 
> The whole point of cpu features is it is initialized as early as possible
> so that it can be used for ifunc.  I don't think __init_tunables is suitable
> for ifunc, which doesn't have any security implications on x86.

It is fine that cpu features (and its overrides) be initialized before
ifunc.  My question is whether we can delay ifunc (and hence cpu
features initialization) enough that tunables can influence them.  Not
only that, ifunc delaying may help other things, like the ability to use
more functions in the resolver to do more complicated things, especially
when they're used outside of glibc.

The latter seems to have use cases, but it is not clear to me yet how
feasible it is.

Siddhesh