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

H.J. Lu hjl.tools@gmail.com
Fri Nov 30 14:28:00 GMT 2018


On Thu, Nov 29, 2018 at 6:12 PM Cary Coutant <ccoutant@gmail.com> wrote:
>
> > 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.
>

Here are what I have on my machine:

[hjl@gnu-cfl-2 compilers]$ readelf -n /lib64/ld-linux-x86-64.so.2  | head

Displaying notes found in: .note.gnu.property
  Owner                 Data size Description
  GNU                  0x00000030 NT_GNU_PROPERTY_TYPE_0
      Properties: x86 feature: IBT, SHSTK
x86 ISA used: CMOV, SSE, SSE2, AVX, AVX512F
x86 feature used: x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC

x86 feature: IBT, SHSTK

is AND/GNU_PROPERTY_X86_FEATURE_1_AND.  It is generated
by GCC with -fcf-protection.

x86 ISA used: CMOV, SSE, SSE2, AVX, AVX512F

is OR_AND/GNU_PROPERTY_X86_ISA_1_USED.  It is generated by
assembler with -mx86-used-note=yes.

x86 feature used: x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC

is OR_AND/GNU_PROPERTY_X86_FEATURE_2_USED.  It is generated
by assembler with -mx86-used-note=yes.

They tell

1.  The binary supports IBT and SHSTK.
2.  The binary only uses base ISA + CMOV, SSE, SSE2, AVX, AVX512F.
3   The binary only uses x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC.

If someone wants to create a set of binaries for AVX2 and above.  He/she
can set AVX2 in OR/GNU_PROPERTY_X86_ISA_1_NEEDED and XMM/YMM
in OR/GNU_PROPERTY_X86_FEATURE_2_NEEDED.

How can I achieve the above with your suggestion?

-- 
H.J.



More information about the Binutils mailing list