RFC: Update GNU_PROPERTY_X86_XXX

[H.J. Lu]

On Wed, Nov 28, 2018 at 8:52 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Wed, Nov 28, 2018 at 4:44 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Tue, Nov 27, 2018 at 11:45 PM Cary Coutant <ccoutant@gmail.com> wrote:
> > >
> > > > 3 kinds of properties provide answers for different questions:
> > > >
> > > > 1. AND:  Do all input relocatables have the feature?
> > > > 2. OR:  Does any input relocatables have the feature?
> > > > 3. OR_AND:  Do all input relocatables have the property and
> > > > some inputs have the feature? In turn, it can tell if none of input
> > > > relocatables have the feature.
> > > >
> > > > It works better to keep both OR and OR_AND.
> > >
> > > You can tell if none of the input relocatables have the feature only
> > > if *all* of the input relocatables have the property. If even one of
> > > the input relocatables is missing the property, you lose all the
> > > feature bits -- you're discarding potentially useful information.
> > > Remember, all the 1 bits are trustworthy even if a relocatable is
> > > missing the property; it's the 0 bits that might not be accurate
> > > (i.e., some of them might have been 1, depending on features used by
> > > the objects missing the property info).
> >
> > 1 bits are accurate for AND, OR and OR_AND.  0 bits are accurate only
> > for OR_AND.
> >
> > > So now what do you expect the loader to do with the information in the
> > > property note? If you have feature bits, presumably it will compare
> > > the 1 bits with the available features on the hardware, and refuse to
> > > run the program if its demands exceed the available features. And it
> > > could give a meaningful error message explaining exactly which
> > > features are required but not available.
> >
> > Correct.
> >
> > > But what if you've removed the property entirely? Should the loader
> > > refuse to run the program? No, you're going to want it to run anyway,
> > > right? And it'll fail at run time if it tries to use an unavailable
> > > feature. But if you hadn't thrown away those 1 bits, you could still
> > > get a meaningful error message for the features we do know about. A
> > > single new AND bit (or a version number) will tell you the same thing
> > > that a missing property tells you, without throwing away all those
> > > useful bits of information.
> > >
> >
> > AND and OR_AND are used for different purposes:
> >
> > 1.  AND:  It is OK if run-time doesn't have the feature the program supports,
> > like CET.
> > 2. OR_AND: It is not OK if run-time doesn't have the feature the program
> > requires, like needed AVX512
> >
> > OR is informational, like used AVX512:
> >
> > 1 bit: Yes.
> > 0 bit: Unknown.
> >
> > AND and OR_AND are useful for loaders and must be originated by
> > compiler or programmer.   OR may be generated automatically by
> > assembler.
> >
>

I pushed the following changes into hjl/property branch:

commit aa4e331977fd0b39ffef0cf65fae9d3241659cf5
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Wed Nov 28 08:47:44 2018 -0800

    Update GNU_PROPERTY_X86_ISA_1_USED

commit c2c5e7d7c3a0c56cacb2d49898686a3584ff4e77
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Nov 27 13:36:10 2018 -0800

    Update GNU_PROPERTY_X86_XXX
commit d919c05ffef8f40cb7de82a71658dbcce2ef5907
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Nov 27 11:49:21 2018 -0800

    Remove GNU_PROPERTY_X86_UINT32_VALID

The updated x86-64 psABI pdf is at

https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-property.pdf

-- 
H.J.