Re: PING^2: V4 [PATCH] x86: Initialize CPU info via IFUNC relocation [BZ 26203]

Re: PING^2: V4 [PATCH] x86: Initialize CPU info via IFUNC relocation [BZ 26203]

[Sunil Pandey]

On Thu, Oct 15, 2020 at 5:54 AM H.J. Lu via Libc-alpha
<libc-alpha@sourceware.org> wrote:
>
> On Thu, Oct 8, 2020 at 6:22 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Thu, Oct 1, 2020 at 12:50 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Thu, Oct 1, 2020 at 1:46 AM Florian Weimer <fweimer@redhat.com> wrote:
> > > >
> > > > * H. J. Lu:
> > > >
> > > > > diff --git a/sysdeps/x86/cacheinfo.c b/sysdeps/x86/cacheinfo.c
> > > > > index dadec5d58f..65ab29123d 100644
> > > > > --- a/sysdeps/x86/cacheinfo.c
> > > > > +++ b/sysdeps/x86/cacheinfo.c
> > > > > @@ -16,7 +16,9 @@
> > > > >     License along with the GNU C Library; if not, see
> > > > >     <https://www.gnu.org/licenses/>.  */
> > > > >
> > > > > -#if IS_IN (libc)
> > > > > +/* NB: In libc.a, this file is included in libc-static.c.  In libc.so,
> > > > > +   this file is standalone.  */
> > > > > +#if IS_IN (libc) && (defined SHARED || defined _PRIVATE_CPU_FEATURES_H)
> > > >
> > > > libc-static.c should be libc-start.c, I believe.  The “defined
> > > > _PRIVATE_CPU_FEATURES_H” part seems rather indirect.  What exactly are
> > > > you trying to accomplish here?
> > > >
> > > > It looks to me as if this file should included in libc.so, but not
> > > > pulled into ld.so via the rebuild, so maybe you can add an empty
> > > > sysdeps/x86/rtld-cacheinfo.c file instead?
> > > >
> > >
> > > Here is the updated patch.   I also moved files around to prepare
> > > for moving x86 processor cache info to cpu_features in ld.so to
> > > support --list-tunables.
> > >
> >
> > PING:
> >
> > https://sourceware.org/pipermail/libc-alpha/2020-October/118228.html
> >
>
> I will check it in tomorrow if there are no objections.
>
> Thanks.
>
> --
> H.J.

I would like to backport this patch to release branches.
Any comments or objections?

--Sunil

Re: PING^2: V4 [PATCH] x86: Initialize CPU info via IFUNC relocation [BZ 26203]

[Sunil Pandey]

On Mon, May 2, 2022 at 6:59 AM Sunil Pandey <skpgkp2@gmail.com> wrote:
>
> On Thu, Oct 15, 2020 at 5:54 AM H.J. Lu via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
> >
> > On Thu, Oct 8, 2020 at 6:22 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >
> > > On Thu, Oct 1, 2020 at 12:50 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >
> > > > On Thu, Oct 1, 2020 at 1:46 AM Florian Weimer <fweimer@redhat.com> wrote:
> > > > >
> > > > > * H. J. Lu:
> > > > >
> > > > > > diff --git a/sysdeps/x86/cacheinfo.c b/sysdeps/x86/cacheinfo.c
> > > > > > index dadec5d58f..65ab29123d 100644
> > > > > > --- a/sysdeps/x86/cacheinfo.c
> > > > > > +++ b/sysdeps/x86/cacheinfo.c
> > > > > > @@ -16,7 +16,9 @@
> > > > > >     License along with the GNU C Library; if not, see
> > > > > >     <https://www.gnu.org/licenses/>.  */
> > > > > >
> > > > > > -#if IS_IN (libc)
> > > > > > +/* NB: In libc.a, this file is included in libc-static.c.  In libc.so,
> > > > > > +   this file is standalone.  */
> > > > > > +#if IS_IN (libc) && (defined SHARED || defined _PRIVATE_CPU_FEATURES_H)
> > > > >
> > > > > libc-static.c should be libc-start.c, I believe.  The “defined
> > > > > _PRIVATE_CPU_FEATURES_H” part seems rather indirect.  What exactly are
> > > > > you trying to accomplish here?
> > > > >
> > > > > It looks to me as if this file should included in libc.so, but not
> > > > > pulled into ld.so via the rebuild, so maybe you can add an empty
> > > > > sysdeps/x86/rtld-cacheinfo.c file instead?
> > > > >
> > > >
> > > > Here is the updated patch.   I also moved files around to prepare
> > > > for moving x86 processor cache info to cpu_features in ld.so to
> > > > support --list-tunables.
> > > >
> > >
> > > PING:
> > >
> > > https://sourceware.org/pipermail/libc-alpha/2020-October/118228.html
> > >
> >
> > I will check it in tomorrow if there are no objections.
> >
> > Thanks.
> >
> > --
> > H.J.
>
> I would like to backport this patch to release branches.
> Any comments or objections?
>
> --Sunil

I have to stop backporting at 2.33.

There is major x86 restructuring and inter patch dependency in the 2.32 branch.
Resolving backport conflict in the 2.32 branch has a cascading effect
on existing
patches.

--Sunil