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

[H.J. Lu]

On Sat, Dec 1, 2018 at 6:05 PM Cary Coutant <ccoutant@gmail.com> wrote:
>
> > 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?
>
> Before I answer that, let's talk about "NEEDED" vs. "USED".
>
> In the psABI, you have described both ISA_1_USED and FEATURE_2_USED as
> "their support in the hardware is optional". Yet:
>
> (a) You've assigned values for both of these in the OR_AND range,
> which you've described earlier in this thread as meaning "It is not OK
> if run-time doesn't have the feature the program requires."
>
> (b) Your example from ld-linux-x86-64.so.2 shows ISA_1_USED and
> FEATURE_2_USED, but does not use either "NEEDED" property. Based on
> everything you've said so far, I'd expect you to be using ISA_1_NEEDED
> and FEATURE_2_NEEDED instead, and these properties should be in the
> OR_AND range.
>
> Why do CMOV, SSE, SSE2, AVX, and AVX512F go in ISA_1_USED, but AVX2
> goes in ISA_1_NEEDED?

When main () executes AVX2 instructions unconditionally, AVX2 is needed.
main () may also call other functions which use CMOV, SSE, SSE2, AVX,
and AVX512F.

> Why do x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, and XSAVEC go in
> FEATURE_2_USED, but XMM and YMM go in FEATURE_2_NEEDED?

When main () executes instructions with XMM and YMM registers unconditionally,
XMM and YMM are needed.  main () may also call other functions which use
x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, and XSAVEC.

> How exactly are you expecting these properties to be treated by the loader?

For example, it can be used to check if a program contains any SSE instructions.
One may want to build a program without SSE.  It can be used to verify that.
Unlike ISA_1_USED, only 1 bit in ISA_1_NEEDED is accurate.   We can't
use ISA_1_NEEDED to check if a program has any SSE instructions.

> For USED (but optional) features, who is the intended consumer? A
> loader can't use them to reject the program on reduced-capability
> hardware, since those features are described as optional. Code tagged
> with a used-but-optional feature presumably has been written to
> dynamically test for the presence of a capability, and use it if it's
> present, falling back to a less-preferred mechanism if it's not. Such
> a property might be useful for link-time selection of variant
> implementations of a routine, or even for load-time selection, but
> only if the property remains attached to the specific entry point. As
> a binary-wide property, I don't see how it would be of much use. If
> the intended consumer is nothing more than a human reader of objdump
> output, that's fine, but you're going to an awful lot of work if
> that's it.
>
> For NEEDED features, the intent is clearly that the loader can
> determine whether the hardware is capable of executing a particular
> binary, and rejecting it gracefully if it's not (as opposed to letting
> it core dump when it tries to use an absent feature -- or worse!). For
> these, it seems silly to discard the whole set of NEEDED features when
> even a single input file is missing the property -- after all, even if
> that missing input file might need some unique features, it's still
> the case that the ones we do know about from other files are still
> needed, and it's still desirable to let the loader reject the binary
> if it can. This is why I don't really understand your motivation for
> the OR_AND rule.
>

OR_AND is for accurate 0 bit.  Loader may decide to load a program
only if SSE bit is 0.

-- 
H.J.