This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, Dec 14, 2018 at 5:11 AM Michael Matz <matz@suse.de> wrote:
>
> 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.).
>

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?

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]