This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] x86: Don't remove empty x86 properties
On Fri, Dec 14, 2018 at 5:11 AM Michael Matz <firstname.lastname@example.org> wrote:
> On Thu, 13 Dec 2018, H.J. Lu wrote:
> > On Thu, Dec 13, 2018 at 8:43 AM Michael Matz <email@example.com> 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
So for USED property, if the KNOWN/RELIABLE/VALID isn't set, we have
to assume the worst case. Why don't we simply remove the USED property
with 0 KNOWN/RELIABLE/VALID bit?