Document GNU_PROPERTY_X86_XXX

[H.J. Lu]

Hi,

Here is the merge request to document GNU_PROPERTY_X86_XXX:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13

which also covers x86-64 ISA level. Any feedbacks?

Thanks.

--
H.J.

[Jan Beulich]

There's no mention of what the bits of GNU_PROPERTY_X86_FEATURE_1_AND
actually mean (i.e. GNU_PROPERTY_X86_FEATURE_1_IBT et al are missing).
How this is different from GNU_PROPERTY_X86_FEATURE_2_USED also
doesn't become clear. (I additionally wonder in how far the apparently
purely informational GNU_PROPERTY_X86_*_USED are of actual practical
use.)

I further view the wording in the general descriptions ("have the
feature") as problematic wrt the subsequent use in *_USED and
*_NEEDED. What does "have the feature" mean there?

The "property missing" being folded with "bit is zero" also isn't
really satisfactory, as it renders the "bit is zero" case pretty
useless. If all contributing objects have a property, a bit being zero
ought to firmly mean "feature not used".

As expressed earlier (when discussing the gas implementation and its
shortcomings) I view GNU_PROPERTY_X86_FEATURE_2_{X,Y,Z}MM's descriptions
in particular as insufficient. It needs to be spelled out which of the
flags need setting for use of e.g. 128-bit VADDPS, including the
consideration of using the VEX encoding on 512-bit-capable hardware. It
further needs spelling out which of the flags, if any, should become
set for use of e.g. the memory form of VFPCLASS* (besides
GNU_PROPERTY_X86_FEATURE_2_MASK). This similarly applies to e.g. the
memory form of CVTPI2PD wrt GNU_PROPERTY_X86_FEATURE_2_MMX.

Further it wants clarifying which of GNU_PROPERTY_X86_FEATURE_2_{X87,MMX}
{,F}EMMS are expected to turn on.

I may have missed further special cases. Yet any ambiguity the spec
leaves will make it impossible to judge whether a particular behavior
(by any of the tools involved) is correct or buggy.

Finally I think that it isn't a good idea to mix register use indicators
with indicators of use of FXSR and XSAVE*.

Jan

[H.J. Lu]

On Thu, Aug 31, 2023 at 1:33 AM Jan Beulich <jbeu...@suse.com> wrote:
>
> On 31.08.2023 04:59, H.J. Lu wrote:
> > Here is the merge request to document GNU_PROPERTY_X86_XXX:
> >
> > https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13
> >
> > which also covers x86-64 ISA level. Any feedbacks?
>
> There's no mention of what the bits of GNU_PROPERTY_X86_FEATURE_1_AND
> actually mean (i.e. GNU_PROPERTY_X86_FEATURE_1_IBT et al are missing).

The CET bits were removed base on the feedback:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13

I will submit a separate merge request for CET bits.

> How this is different from GNU_PROPERTY_X86_FEATURE_2_USED also
> doesn't become clear. (I additionally wonder in how far the apparently
> purely informational GNU_PROPERTY_X86_*_USED are of actual practical
> use.)
>
> I further view the wording in the general descriptions ("have the
> feature") as problematic wrt the subsequent use in *_USED and
> *_NEEDED. What does "have the feature" mean there?

Looking back, the FEATURE_2 bits may not be as useful as I thought.

> The "property missing" being folded with "bit is zero" also isn't
> really satisfactory, as it renders the "bit is zero" case pretty
> useless. If all contributing objects have a property, a bit being zero
> ought to firmly mean "feature not used".
>
> As expressed earlier (when discussing the gas implementation and its
> shortcomings) I view GNU_PROPERTY_X86_FEATURE_2_{X,Y,Z}MM's descriptions
> in particular as insufficient. It needs to be spelled out which of the
> flags need setting for use of e.g. 128-bit VADDPS, including the
> consideration of using the VEX encoding on 512-bit-capable hardware. It
> further needs spelling out which of the flags, if any, should become
> set for use of e.g. the memory form of VFPCLASS* (besides
> GNU_PROPERTY_X86_FEATURE_2_MASK). This similarly applies to e.g. the
> memory form of CVTPI2PD wrt GNU_PROPERTY_X86_FEATURE_2_MMX.
>
> Further it wants clarifying which of GNU_PROPERTY_X86_FEATURE_2_{X87,MMX}
> {,F}EMMS are expected to turn on.
>
> I may have missed further special cases. Yet any ambiguity the spec
> leaves will make it impossible to judge whether a particular behavior
> (by any of the tools involved) is correct or buggy.
>
> Finally I think that it isn't a good idea to mix register use indicators
> with indicators of use of FXSR and XSAVE*.
>

We can obsolete FEATURE_2 bits if they aren't very useful.

Thanks.

--
H.J.

[H.J. Lu]

I updated the merge request:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13

to remove GNU_PROPERTY_X86_FEATURE_2_USED and
GNU_PROPERTY_X86_FEATURE_2_NEEDED. CET bits
will be added in a separate commit.

Thanks.

--
H.J.

[Jan Beulich]

Well, that addresses only part of my earlier comments. In addition to what
I said earlier, what is the intended use of GNU_PROPERTY_X86_ISA_1_USED?
If purely informational, then like for GNU_PROPERTY_X86_FEATURE_2_USED I
question its value.

As to GNU_PROPERTY_X86_ISA_1_NEEDED, it's not really becoming clear how it
is to be set in individual source files. The merging behavior described
for GNU_PROPERTY_X86_UINT32_OR_{LO,HI} isn't really helpful there: For
GNU_PROPERTY_X86_ISA_1_* it is not spelled out whether lower bits also
need setting when higher ones are set. This can be kind of inferred from
the GNU_PROPERTY_X86_UINT32_OR_{LO,HI} description, but is pretty counter-
intuitive: I'd rather expect just a single bit to be set per object (and
this really would better be an enumeration), with the maximum recorded in
linker output. But that's then not OR anymore, but MAX. It is perhaps not
surprising that right now only ISA_1_USED is ever being created (from
scratch) by any of the GNU binutils components. Yet having people hand-
craft .note section entries (like is done in a few binutils testcases) it
at best cumbersome.

Jan

[H.J. Lu]

GNU_PROPERTY_X86_ISA_1_USED is informational only. I will drop it.

> As to GNU_PROPERTY_X86_ISA_1_NEEDED, it's not really becoming clear how it
> is to be set in individual source files. The merging behavior described
> for GNU_PROPERTY_X86_UINT32_OR_{LO,HI} isn't really helpful there: For
> GNU_PROPERTY_X86_ISA_1_* it is not spelled out whether lower bits also
> need setting when higher ones are set. This can be kind of inferred from

GNU_PROPERTY_X86_ISA_1_NEEDED is used to record the ISA level
and glibc uses this formation to decide if an ELF binary can be loaded based
on the ISA level supported by the CPU at run-time. Since ISA level N
includes ISA level N-1, the highest ISA level bit should be checked, regardless
if the lower ISA level bits are set.

> the GNU_PROPERTY_X86_UINT32_OR_{LO,HI} description, but is pretty counter-
> intuitive: I'd rather expect just a single bit to be set per object (and
> this really would better be an enumeration), with the maximum recorded in
> linker output. But that's then not OR anymore, but MAX. It is perhaps not
> surprising that right now only ISA_1_USED is ever being created (from
> scratch) by any of the GNU binutils components. Yet having people hand-
> craft .note section entries (like is done in a few binutils testcases) it
> at best cumbersome.

The advantage of OR bits is that linker doesn't have to know how bits are
used nor what they mean.

--
H.J.

[Jan Beulich]

On 19.09.2023 17:47, H.J. Lu wrote:
> On Mon, Sep 18, 2023 at 11:45 PM Jan Beulich <jbeu...@suse.com> wrote:
>> As to GNU_PROPERTY_X86_ISA_1_NEEDED, it's not really becoming clear how it
>> is to be set in individual source files. The merging behavior described
>> for GNU_PROPERTY_X86_UINT32_OR_{LO,HI} isn't really helpful there: For
>> GNU_PROPERTY_X86_ISA_1_* it is not spelled out whether lower bits also
>> need setting when higher ones are set. This can be kind of inferred from
>
> GNU_PROPERTY_X86_ISA_1_NEEDED is used to record the ISA level
> and glibc uses this formation to decide if an ELF binary can be loaded based
> on the ISA level supported by the CPU at run-time. Since ISA level N
> includes ISA level N-1, the highest ISA level bit should be checked, regardless
> if the lower ISA level bits are set.

IOW an original producer (like gas) may set just a single bit. I think this
could do with spelling out.

>> the GNU_PROPERTY_X86_UINT32_OR_{LO,HI} description, but is pretty counter-
>> intuitive: I'd rather expect just a single bit to be set per object (and
>> this really would better be an enumeration), with the maximum recorded in
>> linker output. But that's then not OR anymore, but MAX. It is perhaps not
>> surprising that right now only ISA_1_USED is ever being created (from
>> scratch) by any of the GNU binutils components. Yet having people hand-
>> craft .note section entries (like is done in a few binutils testcases) it
>> at best cumbersome.
>
> The advantage of OR bits is that linker doesn't have to know how bits are
> used nor what they mean.

I don't see how MAX would be any different in this regard. It's still only
a mathematical operation to apply to two incoming values.

What you didn't comment on is my remark towards how the note is intended to
be populated.

Jan

[H.J. Lu]

On Tue, Sep 19, 2023 at 9:07 AM Jan Beulich <jbeu...@suse.com> wrote:
>
> On 19.09.2023 17:47, H.J. Lu wrote:
> > On Mon, Sep 18, 2023 at 11:45 PM Jan Beulich <jbeu...@suse.com> wrote:
> >> As to GNU_PROPERTY_X86_ISA_1_NEEDED, it's not really becoming clear how it
> >> is to be set in individual source files. The merging behavior described
> >> for GNU_PROPERTY_X86_UINT32_OR_{LO,HI} isn't really helpful there: For
> >> GNU_PROPERTY_X86_ISA_1_* it is not spelled out whether lower bits also
> >> need setting when higher ones are set. This can be kind of inferred from
> >
> > GNU_PROPERTY_X86_ISA_1_NEEDED is used to record the ISA level
> > and glibc uses this formation to decide if an ELF binary can be loaded based
> > on the ISA level supported by the CPU at run-time. Since ISA level N
> > includes ISA level N-1, the highest ISA level bit should be checked, regardless
> > if the lower ISA level bits are set.
>
> IOW an original producer (like gas) may set just a single bit. I think this
> could do with spelling out.

The ISA level bit should be set by compilers. Assemblers don't need
to do anything special.

> >> the GNU_PROPERTY_X86_UINT32_OR_{LO,HI} description, but is pretty counter-
> >> intuitive: I'd rather expect just a single bit to be set per object (and
> >> this really would better be an enumeration), with the maximum recorded in
> >> linker output. But that's then not OR anymore, but MAX. It is perhaps not
> >> surprising that right now only ISA_1_USED is ever being created (from
> >> scratch) by any of the GNU binutils components. Yet having people hand-
> >> craft .note section entries (like is done in a few binutils testcases) it
> >> at best cumbersome.
> >
> > The advantage of OR bits is that linker doesn't have to know how bits are
> > used nor what they mean.

Did you mean a whole 32-bit value as a single field?

> I don't see how MAX would be any different in this regard. It's still only
> a mathematical operation to apply to two incoming values.
>
> What you didn't comment on is my remark towards how the note is intended to
> be populated.
>

It should be populated by compilers.


--
H.J.

[Jan Beulich]

That would be easiest to handle, yes, but a more narrow (sub-)field might of
course also do.

Jan

[H.J. Lu]

The main difference between bitmask and a multi-bit MAX value is that
bitmask can
only support up to 32 ISA levels. Will 32 ISA levels be sufficient?
With AVX10,
we may need a new ISA level, which is a superset of ISA level 3, but
not a superset
of ISA level 4. A bitmask is easier to deal with such ISA levels.
I prefer bitmask if
32 ISA levels are sufficient.

> Jan
>
> >> I don't see how MAX would be any different in this regard. It's still only
> >> a mathematical operation to apply to two incoming values.
> >>
> >> What you didn't comment on is my remark towards how the note is intended to
> >> be populated.
> >>
> >
> > It should be populated by compilers.
> >
> >
>

--
H.J.

[Jan Beulich]

Is it? Plain OR isn't going to cover it then anymore.

Jan

[H.J. Lu]

All ISA level information is available in bitmask for dynamic linker.


--
H.J.

[Jan Beulich]

On 21.09.2023 18:27, H.J. Lu wrote:
> On Thu, Sep 21, 2023 at 8:29 AM Jan Beulich <jbeu...@suse.com> wrote:
>>
>> On 21.09.2023 17:23, H.J. Lu wrote:
>>> On Thu, Sep 21, 2023 at 12:51 AM Jan Beulich <jbeu...@suse.com> wrote:
>>>> On 19.09.2023 18:15, H.J. Lu wrote:
>>>>> On Tue, Sep 19, 2023 at 9:07 AM Jan Beulich <jbeu...@suse.com> wrote:
>>>>>> On 19.09.2023 17:47, H.J. Lu wrote:
>>>>>>> On Mon, Sep 18, 2023 at 11:45 PM Jan Beulich <jbeu...@suse.com> wrote:
>>>>>>>> As to GNU_PROPERTY_X86_ISA_1_NEEDED, it's not really becoming clear how it
>>>>>>>> is to be set in individual source files. The merging behavior described
>>>>>>>> for GNU_PROPERTY_X86_UINT32_OR_{LO,HI} isn't really helpful there: For
>>>>>>>> GNU_PROPERTY_X86_ISA_1_* it is not spelled out whether lower bits also
>>>>>>>> need setting when higher ones are set. This can be kind of inferred from
>>>>>>>
>>>>>>> GNU_PROPERTY_X86_ISA_1_NEEDED is used to record the ISA level
>>>>>>> and glibc uses this formation to decide if an ELF binary can be loaded based
>>>>>>> on the ISA level supported by the CPU at run-time. Since ISA level N
>>>>>>> includes ISA level N-1, the highest ISA level bit should be checked, regardless
>>>>>>> if the lower ISA level bits are set.

This property ...

... would be violated if there was a new level not being a superset
of 4. Otoh using plain OR to combine values from inputs could still be
viewed as okay, if discontiguous set bits do _not_ have the meaning
ascribed by you in your earlier reply.

Jan

[H.J. Lu]

Correct.

> of 4. Otoh using plain OR to combine values from inputs could still be
> viewed as okay, if discontiguous set bits do _not_ have the meaning
> ascribed by you in your earlier reply.
>

Bitmask supports the possible discontiguous ISA levels.


--
H.J.

[Jan Beulich]

But then the text above needs to be adjusted _before_ any discontiguous
levels are introduced. Which imo means documenting in that way from the
beginning.

Jan

[H.J. Lu]

Can you put your text change suggestions in

https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13/diffs?commit_id=bf0d9a58092cdd43b6bd6d350c6074f577b07902

Thanks.

--
H.J.

[Jan Beulich]

> Can you put your text change suggestions in
>
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13/diffs?commit_id=bf0d9a58092cdd43b6bd6d350c6074f577b07902

I realize I still owe you a reply here: I'm afraid I have no good
suggestions, and I'm further afraid I wouldn't be happy to use gitlab's
merge request model either. As the proponent of this functionality I'd
kind of expect you to be able to word its documentation in a technically
accurate manner.

I'm sorry, Jan