[PATCH] x86: Don't remove empty x86 properties

[Cary Coutant]

> 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.

Isn't this the opposite of what you have in the psABI?

    GNU_PROPERTY_X86_FEATURE_2_USED [which is OR_AND] The x86
    processor features indicated by the corresponding bits are
    used in program. Their support in the hardware is optional.
    Its absence in an x86 ELF binary implies that any x86
    processor features may be used.

    GNU_PROPERTY_X86_FEATURE_2_NEEDED [which is OR] The x86
    processor features indicated by the corresponding bits are
    used in program and they must be supported by the hardware.

What you've written in your email makes more sense, which suggests
that you've got the values for the USED and NEEDED properties reversed
in the psABI.

But the point I've been trying to make is that your OR_AND rule is
needlessly coarse-grained -- if any input object is missing a property
note, you discard information about features that we can know are
needed. Let's take a high-level look at what we're trying to track...

The NEEDED properties that indicate what hardware features are needed
for execution (what should be OR_AND in your scheme) are conceptually
tri-state properties for each feature:

    NO: the program does not need this feature
    YES: the program does need this feature
    UNK: it is unknown because one or more objects didn't specify

If we were to keep track of the state of each individual feature, we'd
want to combine states as follows:

   NO + NO -> NO
   UNK + NO -> UNK
   UNK + UNK -> UNK
   YES + X -> YES

One way to track the state for each property individually would be to
use two separate bit masks: FEATURE_X_KNOWN and FEATURE_X_NEEDED. The
KNOWN properties would use the AND combining rule, and the NEEDED
properties would use the OR combining rule. The various combinations
would have the following meanings:

   K = 0 & N = 0: UNK
   K = 1 & N = 0: NO (not needed)
   K = X & N = 1: YES (needed)

(where K and N are the corresponding bits for any specific feature
from FEATURE_X_KNOWN and FEATURE_X_NEEDED, respectively).

This would let the linker keep track of the state of each individual
property, and the loader could correctly refuse to run a program that
needs an unavailable feature even if one or more input objects lack
the property notes. A missing property note would force all the NOs to
UNKs, but would leave the YESes alone.

Also, in this scheme (as with my earlier suggestions of using a single
FEATURE_1_AND bit or a version number), a missing property always
means the same as a property with all zeroes.

With your approach, where you represent the UNK state by a missing
property, any missing property note forces *all* features to the UNK
state, even if we can state for sure that a feature is needed.

-cary