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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Nov 27, 2018 at 3:05 PM Cary Coutant <ccoutant@gmail.com> wrote:
>
> Thanks, this is much clearer:
>
> > GNU_PROPERTY_X86_UINT32_AND_LO..GNU_PROPERTY_X86_UINT32_AND_HI
> > A bit in the output pr_data field is set only if it is set in all
> > relocatable input pr_data
> > fields. If all bits in the the output pr_data field are zero, this
> > property should be
> > removed from output.
> >
> > GNU_PROPERTY_X86_UINT32_OR_LO..GNU_PROPERTY_X86_UINT32_OR_HI
> > A bit in the output pr_data field is set if it is set in any
> > relocatable input pr_data
> > fields. If all bits in the the output pr_data field are zero, this
> > property should be
> > removed from output.
> >
> > GNU_PROPERTY_X86_UINT32_OR_AND_LO..GNU_PROPERTY_X86_UINT32_OR_AND_HI
> > A bit in the output pr_data field is set if it is set in any
> > relocatable input pr_data
> > fields and this property is present in all relocatable input files. A
> > missing property
> > implies that its bits may have any values. When all bits in the the
> > output pr_data
> > field are zero, this property should not be removed from output.
>
> So the "linker must not remove properties with all zeroes" rule is
> only for the OR_AND properties, right? That is, ISA_1_USED and
> FEATURE_2_USED. And the rationale for this rule is that any object
> that doesn't contain the property is presumed old and therefore uses
> an unknown set of ISAs and FEATUREs. But an object that does contain a
> property with all zeroes uses only the base ISA or no extra FEATUREs.

That is correct.

> What's the point of the rule that ISA_1_USED is "valid only if
> GNU_PROPERTY_X86_FEATURE_2_USED type is also present"?

I will remove it.

> It might have been simpler to define a bit in FEATURE_1_AND to
> indicate that the object is not old and that its ISA and FEATURE bits
> can be trusted (even if missing and assumed zero). The OR_AND
> properties could then just be simple OR properties, and a missing
> property would be synonymous with all zero bits. If that new bit is
> off in the output file, the loader would know that the ISA and FEATURE
> bits may not completely describe the object.

3 kinds of properties provide answers for different questions:

1. AND:  Do all input relocatables have the feature?
2. OR:  Does any input relocatables have the feature?
3. OR_AND:  Do all input relocatables have the property and
some inputs have the feature? In turn, it can tell if none of input
relocatables have the feature.

It works better to keep both OR and OR_AND.

> A version number might be even more useful, since we've already seen
> two or three revisions since this scheme was first deployed. Define a
> new property with an integer value and a "MIN" combining rule that
> says to output the minimum of all values seen in the input objects
> (where an object with a missing property is taken as version 0). As an
> example, this would cover you if you decide at some point in the
> future to define a new ISA or FEATURE bit to represent some feature
> that may already be in use in some existing objects.

We have enough values to go around.   I don't think it is necessary.


-- 
H.J.