V3 [PATCH] x86: Initialize CPU info via IFUNC relocation [BZ 26203]

["H.J. Lu" <hjl.tools@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]

On Mon, Sep 28, 2020 at 7:47 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > On Mon, Sep 28, 2020 at 7:22 AM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> * H. J. Lu:
> >>
> >> > We want to call init_cacheinfo as early as possible.  __libc_early_init is
> >> > still too late.
> >>
> >> My point is that we should call it from IFUNC resolvers that need it,
> >> and from __libc_early_init.  That should cover all cases, no?
> >
> > Why call it from __libc_early_init after it has been called by
> > IFUNC reloc?  IFUNC relocations are processed before
> > __libc_early_init is called.
>
> IFUNC relocations might not existing in a --disable-multi-arch build,
> but it may still need the cacheinfo data if the hard-coded
> implementations need them.

IFUNC is always supported on x86.  multi-arch uses IFUNC, not
the other way around.

> We would still run the IFUNC resolver for the artificial IFUNC resolver
> with its function pointer, but:
>
> My concern is that you seem to have a specific ordering dependency on
> IFUNC resolvers, and I would like to get rid of that: Initialize the
> necessary data on demand (for string function selection), and during
> __libc_early_init for potential use from string functions.
>
> I hope this clarifies what I'm looking for.  Please let me know if this
> is not reasonable.
>

Here is the updated patch.  Does it address your concerns?

Thanks.

-- 
H.J.

[-- Attachment #2: 0001-x86-Initialize-CPU-info-via-IFUNC-relocation-BZ-2620.patch --]
[-- Type: application/x-patch, Size: 13398 bytes --]