OR_AND semantics (was: GNU property saga)

[Michael Matz <matz at suse dot de>]

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

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?


Ciao,
Michael.