OR_AND semantics (was: GNU property saga)

[H.J. Lu]

On Tue, Mar 5, 2019 at 1:40 AM Michael Matz <matz@suse.de> wrote:
>
> Hi,
>
> On Mon, 4 Mar 2019, Michael Matz wrote:
>
> > Was there ever consensus on the OR_AND thingy?  It strikes me as not
> > really implementing what is wanted, especially in relation to future
> > extensibility (I'll write a mail about this).
>
> So, starting a subthread about only this.  The current description of the
> OR_AND range is this:
>
> ----------------
> \item[GNU_PROPERTY_X86_UINT32_OR_AND_LO..GNU_PROPERTY_X86_UINT32_OR_AND_HI]
>    A bit in the output \code{pr_data} field is set if it is set in any
>    relocatable input \code{pr_data} fields and this property is present
>    in all relocatable input files.  A missing property implies that its
>    bits have unknown values.  When all bits in the the output
>    \code{pr_data} field are zero, this property should not be removed
>    from output to indicate it has zero in all bits.  If the property
>    is in output, all input relocatables have the property.  If the bit
>    is 1, some input relocatables have the feature.  If the bit is 0,
> 
>    none of input relocatables have the feature.
> ----------------
>
> So, it's clear that the individual bits of the uint32 are independend of
> each other and hence can represent separate features/properties.  This
> means that the phrase "and this property is present in all relocatable
> input files" in not well defined: example situation:
>
> * producer A knows about bits 4 and 5 of FEATURE_X (assumed to be in the
>   OR_AND range), it will set the FEATURE_X property in a.o (and bit 4
>   and 5 therein to whatever is correct/requested)
> * producer B is older and happens to know only bit 4 of FEATURE_X, so it
>   will set FEATURE_X in b.o, and bit 4 to whatever value is correct, but
>   bit 5 will be zero.
>
> Now the above language would include FEATURE_X in the output, but bit 4
> would be reliable (set a.bit4 && b.bit4) while bit 5 would be unreliable
> (it is zero, even if it is one in a.o and _would_ be one in b.o had we
> used a newer producer).

We can't add a bit to FEATURE_X in such a way that  FEATURE_X generated
by older producers become invalid.   We must add the bit to FEATURE_Y which is
unsupported to all prior producers.  Am I missing something obvious?

> So there's still the confusion between absense and zero-is-unknown and
> zero-is-known, which the OR_AND range was designed to make clear (at least
> as far as I understood it from various mails trying to explain situations
> in which it would help).
>
> So, either I misunderstood the reason of existence for OR_AND, or there's
> some unspelled assumption in the usage of OR_AND (e.g. that there must
> never be producers knowing a different set of bits per FEATURE_xxx uint32
> set), or the language above doesn't capture the intent.
>
> What is it?
>

-- 
H.J.