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

[Cary Coutant <ccoutant at gmail dot com>]

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

You haven't responded to this. Either the psABI is wrong or your
explanation earlier in this thread about OR_AND is wrong. Which is it?

In bfd, you treat the USED properties as OR_AND properties, where you
remove the property if one file doesn't provide it, and you treat the
NEEDED properties as OR properties. Given the psABI descriptions of
the USED and NEEDED properties, I think you've got them backwards.

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

It sounds like you're telling me that you use NEEDED to describe
features that main() uses, and USED to describe what features may be
used by functions that main() calls. That can't be what you mean --
how is that a useful distinction? And how would the linker even
determine that?

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

Please explain what you expect the loader (and other consumers) to do
with the USED and NEEDED bits. This explanation ought to be in the
psABI.

-cary