Re: [PATCH v3] x86: Disable x86-64 level marker [BZ #27318]

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

On Mon, Mar 1, 2021 at 8:06 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Florian Weimer:
>
> > * H. J. Lu via Libc-alpha:
> >
> >> On Mon, Feb 22, 2021 at 2:40 AM Florian Weimer <fweimer@redhat.com> wrote:
> >>> I think this will produce an #error for if there is a lone -mavx in
> >>> addition to x86-64-v2 coverage in the compiler.  The first block would
> >>> define ISA_V2, but the second block produces the error.  I assume that
> >>> causes inclusion of the build note to be skipped.
> >>
> >> Correct.
> >
> > Okay, that explains why the checks are the way they are.  Thanks.
> >
> >>> Is this really helpful?  If glibc was built to run with on x86-64-v2
> >>> CPUs with some extra, wouldn't it still make sense to perform the
> >>> x86-64-v2 diagnostic upon startup?
> >>
> >> Since libc.so now contains x86-64-v2 + extra, we can't mark it as
> >> x86-64-v2 since it may UD on x86-64-v2 machines.  Or we can
> >> change the meaning of the ISA level marker from "this shared library
> >> REQUIRES ONLY x86-64-v2 to run" to "this shared library WON'T
> >> run without x86-64-v2".
> >
> > I think the loader check is worthwhile to add because otherwise people
> > will end up with half-working systems.  In my experience, this can lead
> > to lots of bug reports because people assume that if only some things
> > are crashing, it must be a distribution bug.  So the loader check is
> > quite valuable for documenting an baseline increase.
> >
> > I also think that the ELF markers are valuable if they specify the exact
> > ABI level to which the object has been built.  But I do think we need
> > GCC and perhaps binutils support for generating them because otherwise,
> > new GCC features may silently build glibc with the wrong ABI level.  For
> > example, with this patch and building on GCC 10 with
> > -march=icelake-server, it seems like I still get a property note:
> >
> > Displaying notes found in: .note.gnu.property
> >   Owner                Data size      Description
> >   GNU                  0x00000010     NT_GNU_PROPERTY_TYPE_0        Properties: <procesor-specific type 0xc0008002 data: 0f 00 00 00 >
> >
> > But -march=icelake-server is a superset of x86-64-v4, so that's not
> > correct, I think.  glibc can't know a bout all these extra features, so
> > the generated note will always be misleading.  A note produced elsewhere
> > in the toolchain would not have this problem.
> >
> > But we could still check for all the preprocessor macros we know that
> > should constitute x86-64-v2 &c, and error out in the dynamic loader if
> > there isn't support for them in the current process.
>
> Any further comments here?
>
> This bug keeps hitting more and more people.
>
> I think we should do the following: (a) disable the build note
> generation in glibc, (b) backport --list-diagnostics or something
> similar.  The second part will hopefully help with analyzing failures
> due to CPU support mismatches.

My patch does (a).  But I think the ISA level meaning should be changed
from "works on processors with the ISA level" to "require processors with
the ISA level to work".

-- 
H.J.