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

[Michael Matz]

Hi,

On Thu, 13 Dec 2018, H.J. Lu wrote:

> On Thu, Dec 13, 2018 at 8:43 AM Michael Matz <matz@suse.de> wrote:
> >
> > Hi,
> >
> > On Thu, 13 Dec 2018, H.J. Lu wrote:
> >
> > > > In principle, whenever you have turned on generation of the property
> > > > bit, you set the associated known bit.  Now, what your OR_AND
> > > > construct turns into a one bit is represented by known=1 and
> > > > property=1 in the output.  But you can distinguish between the other
> > > > three cases, all of which get mapped to zero by your mechanism (or
> > > > absent, except that as I noted before, you can't reasonably do absent
> > > > in the middle of a word of such bits).
> > >
> > > 1 bit isn't an issue.  0 bit is tricky.  In case of USED property, 0 bit
> > > means that the feature isn't used.  When combining 2 objects, one has
> > > the USED property and the other doesn't, how do you perform such OR
> > > operation?
> >
> > With a logical bit-or.  The result of combining both of course has the
> > feature USED.  That is when both inputs have their KNOWN/RELIABLE/VALID
> > bit set for that feature.  If one of them doesn't have it set, then the
> > USED bit is unreliable in this single object, and hence also in the
> > result.  Which means a logical bit-and for the KNOWN bits and bit-or for
> > USED bits.  That results in unknown-used here, which makes sense when
> > interpreting as "feature is used but there were some unreliable inputs".
> >
> > In this specific case (combining known-used with unknown-unused) one
> > might also decide to leave the KNOWN bit on (to known-used) if you know
> > something about the particular feature: if the bit setting is such that
> > USED is less conservative than UNUSED then unknown-unused is "at worst"
> > unknown-used, which combines just fine with known-used to known-used.  But
> > if you know nothing about the bits (as generic tools shouldn't) the
> > correct path through this lattice of knowledge-usedness is and-or.
> >
> > (This (non)knowledge of feature specifics is actually what makes the
> > difference between unknown-used and unknown-unused.  If you know what of
> > used/unused is more conservative, either unknown-used can be mapped to
> > known-used or unknown-unused to known-unused without loss of information.
> > But you can only do that mapping if you know the semantics of the feature,
> > which is why you need both states in generic tools).
> 
> For the USED property, if the KNOWN/RELIABLE/VALID isn't set, its 1 bits 
> are valid.  But its 0 bits are invalid.  So it contains the same 
> information as absence of this property.  Am I correct?

Well, also the 1 bits are unreliable.  But of course nothing would 
willy-nilly set those bits except it has a real reason for doing so, so 
inferring from the bit being set that the feature is used, even if it says 
"unknown", seems sensible.  That's what I meant in my last paragraph.  But 
think about negative feature bits (i.e. where non-usage is important, like 
noexecstack), there you wouldn't want to infer anything from unkown-used.

(Basically for unknown-anything you have to assume the worst case for this 
particular feature, and that may either be "is used" or "isn't used".  
With instruction subsets the worst case will usually be "is used" of 
course.).


Ciao,
Michael.