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

[H.J. Lu]

Since empty x86 properties contain valid information, they shouldn't be
removed.

bfd/

PR ld/23372
PR ld/23515
* elfxx-x86.c (_bfd_x86_elf_merge_gnu_properties): Don't remove
empty properties.
(_bfd_x86_elf_link_fixup_gnu_properties): Likewise.

ld/

PR ld/23372
PR ld/23515
* testsuite/ld-i386/ibt-plt-2a.d: Updated.
* testsuite/ld-i386/ibt-plt-2b.d: Likewise.
* testsuite/ld-i386/pr23372a.d: Likewise.
* testsuite/ld-i386/pr23372b.d: Likewise.
* testsuite/ld-i386/pr23372c.d: Likewise.
* testsuite/ld-i386/pr23372d.d: Likewise.
* testsuite/ld-i386/property-3.r: Likewise.
* testsuite/ld-i386/property-4.r: Likewise.
* testsuite/ld-i386/property-5.r: Likewise.
* testsuite/ld-i386/property-x86-ibt1a.d: Likewise.
* testsuite/ld-i386/property-x86-ibt1b.d: Likewise.
* testsuite/ld-i386/property-x86-shstk1a.d: Likewise.
* testsuite/ld-i386/property-x86-shstk1b.d: Likewise.
* testsuite/ld-x86-64/ibt-plt-2a-x32.d: Likewise.
* testsuite/ld-x86-64/ibt-plt-2a.d: Likewise.
* testsuite/ld-x86-64/ibt-plt-2b-x32.d: Likewise.
* testsuite/ld-x86-64/ibt-plt-2b.d: Likewise.
* testsuite/ld-x86-64/pr23372a-x32.d: Likewise.
* testsuite/ld-x86-64/pr23372a.d: Likewise.
* testsuite/ld-x86-64/pr23372b-x32.d: Likewise.
* testsuite/ld-x86-64/pr23372b.d: Likewise.
* testsuite/ld-x86-64/pr23372c-x32.d: Likewise.
* testsuite/ld-x86-64/pr23372c.d: Likewise.
* testsuite/ld-x86-64/pr23372d-x32.d: Likewise.
* testsuite/ld-x86-64/pr23372d.d: Likewise.
* testsuite/ld-x86-64/property-3.r: Likewise.
* testsuite/ld-x86-64/property-4.r: Likewise.
* testsuite/ld-x86-64/property-5.r: Likewise.
* testsuite/ld-x86-64/property-x86-ibt1a-x32.d: Likewise.
* testsuite/ld-x86-64/property-x86-ibt1a.d: Likewise.
* testsuite/ld-x86-64/property-x86-ibt1b-x32.d: Likewise.
* testsuite/ld-x86-64/property-x86-ibt1b.d: Likewise.
* testsuite/ld-x86-64/property-x86-shstk1a-x32.d: Likewise.
* testsuite/ld-x86-64/property-x86-shstk1a.d: Likewise.
* testsuite/ld-x86-64/property-x86-shstk1b-x32.d: Likewise.
* testsuite/ld-x86-64/property-x86-shstk1b.d: Likewise.
---
bfd/elfxx-x86.c | 40 +++----------------
ld/testsuite/ld-i386/ibt-plt-2a.d | 22 +++++-----
ld/testsuite/ld-i386/ibt-plt-2b.d | 25 +++++++-----
ld/testsuite/ld-i386/pr23372a.d | 5 +++
ld/testsuite/ld-i386/pr23372b.d | 5 +++
ld/testsuite/ld-i386/pr23372c.d | 5 +++
ld/testsuite/ld-i386/pr23372d.d | 5 +++
ld/testsuite/ld-i386/property-3.r | 1 +
ld/testsuite/ld-i386/property-4.r | 1 +
ld/testsuite/ld-i386/property-5.r | 1 +
ld/testsuite/ld-i386/property-x86-ibt1a.d | 5 ++-
ld/testsuite/ld-i386/property-x86-ibt1b.d | 5 ++-
ld/testsuite/ld-i386/property-x86-shstk1a.d | 5 ++-
ld/testsuite/ld-i386/property-x86-shstk1b.d | 5 ++-
ld/testsuite/ld-x86-64/ibt-plt-2a-x32.d | 24 +++++------
ld/testsuite/ld-x86-64/ibt-plt-2a.d | 24 +++++------
ld/testsuite/ld-x86-64/ibt-plt-2b-x32.d | 19 +++++----
ld/testsuite/ld-x86-64/ibt-plt-2b.d | 19 +++++----
ld/testsuite/ld-x86-64/pr23372a-x32.d | 5 +++
ld/testsuite/ld-x86-64/pr23372a.d | 5 +++
ld/testsuite/ld-x86-64/pr23372b-x32.d | 5 +++
ld/testsuite/ld-x86-64/pr23372b.d | 5 +++
ld/testsuite/ld-x86-64/pr23372c-x32.d | 5 +++
ld/testsuite/ld-x86-64/pr23372c.d | 5 +++
ld/testsuite/ld-x86-64/pr23372d-x32.d | 5 +++
ld/testsuite/ld-x86-64/pr23372d.d | 5 +++
ld/testsuite/ld-x86-64/property-3.r | 1 +
ld/testsuite/ld-x86-64/property-4.r | 1 +
ld/testsuite/ld-x86-64/property-5.r | 1 +
.../ld-x86-64/property-x86-ibt1a-x32.d | 5 ++-
ld/testsuite/ld-x86-64/property-x86-ibt1a.d | 5 ++-
.../ld-x86-64/property-x86-ibt1b-x32.d | 5 ++-
ld/testsuite/ld-x86-64/property-x86-ibt1b.d | 5 ++-
.../ld-x86-64/property-x86-shstk1a-x32.d | 5 ++-
ld/testsuite/ld-x86-64/property-x86-shstk1a.d | 5 ++-
.../ld-x86-64/property-x86-shstk1b-x32.d | 5 ++-
ld/testsuite/ld-x86-64/property-x86-shstk1b.d | 5 ++-
37 files changed, 181 insertions(+), 118 deletions(-)

diff --git a/bfd/elfxx-x86.c b/bfd/elfxx-x86.c
index 05f5c6a2f9..425f9a1495 100644
--- a/bfd/elfxx-x86.c
+++ b/bfd/elfxx-x86.c
@@ -2427,34 +2427,14 @@ _bfd_x86_elf_merge_gnu_properties (struct bfd_link_info *info,
or_property:
number = aprop->u.number;
aprop->u.number = number | bprop->u.number;
- /* Remove the property if all bits are empty. */
- if (aprop->u.number == 0)
- {
- aprop->pr_kind = property_remove;
- updated = TRUE;
- }
- else
- updated = number != (unsigned int) aprop->u.number;
+ updated = number != (unsigned int) aprop->u.number;
}
else
{
- /* Only one of APROP and BPROP can be NULL. */
- if (aprop != NULL)
- {
- if (aprop->u.number == 0)
- {
- /* Remove APROP if all bits are empty. */
- aprop->pr_kind = property_remove;
- updated = TRUE;
- }
- }
- else
- {
- /* Return TRUE if APROP is NULL and all bits of BPROP
- aren't empty to indicate that BPROP should be added
- to ABFD. */
- updated = bprop->u.number != 0;
- }
+ /* Only one of APROP and BPROP can be NULL. Return TRUE if
+ BPROP isn't NULL to indicate that BPROP should be added
+ to ABFD. */
+ updated = bprop != NULL;
}
return updated;
}
@@ -2478,9 +2458,6 @@ or_property:
GNU_PROPERTY_X86_FEATURE_1_SHSTK. */
aprop->u.number = (number & bprop->u.number) | features;
updated = number != (unsigned int) aprop->u.number;
- /* Remove the property if all feature bits are cleared. */
- if (aprop->u.number == 0)
- aprop->pr_kind = property_remove;
}
else
{
@@ -2941,13 +2918,6 @@ _bfd_x86_elf_link_fixup_gnu_properties (struct bfd_link_info *info,
|| (type >= GNU_PROPERTY_X86_UINT32_OR_AND_LO
&& type <= GNU_PROPERTY_X86_UINT32_OR_AND_HI))
{
- if (p->property.u.number == 0)
- {
- /* Remove empty property. */
- *listp = p->next;
- continue;
- }
-
/* Mark x86-specific properties with X86_UINT32_VALID for
non-relocatable output. */
if (!bfd_link_relocatable (info))
diff --git a/ld/testsuite/ld-i386/ibt-plt-2a.d b/ld/testsuite/ld-i386/ibt-plt-2a.d
index 5825be43f4..ee8ec98bd4 100644
--- a/ld/testsuite/ld-i386/ibt-plt-2a.d
+++ b/ld/testsuite/ld-i386/ibt-plt-2a.d
@@ -8,45 +8,45 @@

Disassembly of section .plt:

-0+140 <.plt>:
+[a-f0-9]+ <.plt>:
+[a-f0-9]+: ff b3 04 00 00 00 pushl 0x4\(%ebx\)
+[a-f0-9]+: ff a3 08 00 00 00 jmp \*0x8\(%ebx\)
+[a-f0-9]+: 0f 1f 40 00 nopl 0x0\(%eax\)
+[a-f0-9]+: f3 0f 1e fb endbr32
+[a-f0-9]+: 68 00 00 00 00 push \$0x0
- +[a-f0-9]+: e9 e2 ff ff ff jmp 140 <.plt>
+ +[a-f0-9]+: e9 e2 ff ff ff jmp [a-f0-9]+ <.plt>
+[a-f0-9]+: 66 90 xchg %ax,%ax
+[a-f0-9]+: f3 0f 1e fb endbr32
+[a-f0-9]+: 68 08 00 00 00 push \$0x8
- +[a-f0-9]+: e9 d2 ff ff ff jmp 140 <.plt>
+ +[a-f0-9]+: e9 d2 ff ff ff jmp [a-f0-9]+ <.plt>
+[a-f0-9]+: 66 90 xchg %ax,%ax

Disassembly of section .plt.sec:

-0+170 <***@plt>:
+[a-f0-9]+ <***@plt>:
+[a-f0-9]+: f3 0f 1e fb endbr32
+[a-f0-9]+: ff a3 0c 00 00 00 jmp \*0xc\(%ebx\)
+[a-f0-9]+: 66 0f 1f 44 00 00 nopw 0x0\(%eax,%eax,1\)

-0+180 <***@plt>:
+[a-f0-9]+ <***@plt>:
+[a-f0-9]+: f3 0f 1e fb endbr32
+[a-f0-9]+: ff a3 10 00 00 00 jmp \*0x10\(%ebx\)
+[a-f0-9]+: 66 0f 1f 44 00 00 nopw 0x0\(%eax,%eax,1\)

Disassembly of section .text:

-0+190 <foo>:
+[a-f0-9]+ <foo>:
+[a-f0-9]+: 53 push %ebx
- +[a-f0-9]+: e8 18 00 00 00 call 1ae <__x86.get_pc_thunk.bx>
- +[a-f0-9]+: 81 c3 1a 11 00 00 add \$0x111a,%ebx
+ +[a-f0-9]+: e8 18 00 00 00 call [a-f0-9]+ <__x86.get_pc_thunk.bx>
+ +[a-f0-9]+: 81 c3 ([0-9a-f]{2} ){4}[ ]+add \$0x[a-f0-9]+,%ebx
+[a-f0-9]+: 83 ec 08 sub \$0x8,%esp
- +[a-f0-9]+: e8 dc ff ff ff call 180 <***@plt>
- +[a-f0-9]+: e8 c7 ff ff ff call 170 <***@plt>
+ +[a-f0-9]+: e8 dc ff ff ff call [a-f0-9]+ <***@plt>
+ +[a-f0-9]+: e8 c7 ff ff ff call [a-f0-9]+ <***@plt>
+[a-f0-9]+: 83 c4 08 add \$0x8,%esp
+[a-f0-9]+: 5b pop %ebx
+[a-f0-9]+: c3 ret

-0+1ae <__x86.get_pc_thunk.bx>:
+[a-f0-9]+ <__x86.get_pc_thunk.bx>:
+[a-f0-9]+: 8b 1c 24 mov \(%esp\),%ebx
+[a-f0-9]+: c3 ret
#pass
diff --git a/ld/testsuite/ld-i386/ibt-plt-2b.d b/ld/testsuite/ld-i386/ibt-plt-2b.d
index 0fa9a998f1..f62e062c6d 100644
--- a/ld/testsuite/ld-i386/ibt-plt-2b.d
+++ b/ld/testsuite/ld-i386/ibt-plt-2b.d
@@ -18,31 +18,36 @@ Contents of the .eh_frame section:
DW_CFA_nop
DW_CFA_nop

-0+18 0000001c 0000001c FDE cie=00000000 pc=00000190..000001ae
- DW_CFA_advance_loc: 1 to 00000191
+0+18 0000001c 0000001c FDE cie=00000000 pc=[a-f0-9]+\.\.[a-f0-9]+
+ DW_CFA_advance_loc: 1 to [a-f0-9]+
DW_CFA_def_cfa_offset: 8
DW_CFA_offset: r3 \(ebx\) at cfa-8
- DW_CFA_advance_loc: 14 to 0000019f
+ DW_CFA_advance_loc: 14 to [a-f0-9]+
DW_CFA_def_cfa_offset: 16
- DW_CFA_advance_loc: 13 to 000001ac
+ DW_CFA_advance_loc: 13 to [a-f0-9]+
DW_CFA_def_cfa_offset: 8
- DW_CFA_advance_loc: 1 to 000001ad
+ DW_CFA_advance_loc: 1 to [a-f0-9]+
DW_CFA_restore: r3 \(ebx\)
DW_CFA_def_cfa_offset: 4

-0+38 00000010 0000003c FDE cie=00000000 pc=000001ae..000001b2
+0+38 00000010 0000003c FDE cie=00000000 pc=[a-f0-9]+\.\.[a-f0-9]+
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop

-0+4c 00000020 00000050 FDE cie=00000000 pc=00000140..00000170
+0+4c 00000020 00000050 FDE cie=00000000 pc=[a-f0-9]+\.\.[a-f0-9]+
DW_CFA_def_cfa_offset: 8
- DW_CFA_advance_loc: 6 to 00000146
+ DW_CFA_advance_loc: 6 to [a-f0-9]+
DW_CFA_def_cfa_offset: 12
- DW_CFA_advance_loc: 10 to 00000150
+ DW_CFA_advance_loc: 10 to [a-f0-9]+
DW_CFA_def_cfa_expression \(DW_OP_breg4 \(esp\): 4; DW_OP_breg8 \(eip\): 0; DW_OP_lit15; DW_OP_and; DW_OP_lit9; DW_OP_ge; DW_OP_lit2; DW_OP_shl; DW_OP_plus\)

-0+70 00000010 00000074 FDE cie=00000000 pc=00000170..00000190
+0+70 00000010 00000074 FDE cie=00000000 pc=[a-f0-9]+\.\.[a-f0-9]+
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature: <None>
diff --git a/ld/testsuite/ld-i386/pr23372a.d b/ld/testsuite/ld-i386/pr23372a.d
index b75523bdc3..7af7efb065 100644
--- a/ld/testsuite/ld-i386/pr23372a.d
+++ b/ld/testsuite/ld-i386/pr23372a.d
@@ -3,3 +3,8 @@
#as: --32
#ld: -r -m elf_i386
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA used:
diff --git a/ld/testsuite/ld-i386/pr23372b.d b/ld/testsuite/ld-i386/pr23372b.d
index a8e9c819a4..af1a6407a0 100644
--- a/ld/testsuite/ld-i386/pr23372b.d
+++ b/ld/testsuite/ld-i386/pr23372b.d
@@ -3,3 +3,8 @@
#as: --32
#ld: -r -m elf_i386
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA needed:
diff --git a/ld/testsuite/ld-i386/pr23372c.d b/ld/testsuite/ld-i386/pr23372c.d
index 987ae4cfe5..d5bcc4d7b2 100644
--- a/ld/testsuite/ld-i386/pr23372c.d
+++ b/ld/testsuite/ld-i386/pr23372c.d
@@ -3,3 +3,8 @@
#as: --32
#ld: -r -m elf_i386
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA used:
diff --git a/ld/testsuite/ld-i386/pr23372d.d b/ld/testsuite/ld-i386/pr23372d.d
index e44aee9d5c..c286bf4840 100644
--- a/ld/testsuite/ld-i386/pr23372d.d
+++ b/ld/testsuite/ld-i386/pr23372d.d
@@ -3,3 +3,8 @@
#as: --32
#ld: -r -m elf_i386
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA needed:
diff --git a/ld/testsuite/ld-i386/property-3.r b/ld/testsuite/ld-i386/property-3.r
index e9f7162357..b4f9976c56 100644
--- a/ld/testsuite/ld-i386/property-3.r
+++ b/ld/testsuite/ld-i386/property-3.r
@@ -3,5 +3,6 @@ Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
Properties: stack size: 0x800000
+#...
x86 ISA needed: CMOV, SSE
#pass
diff --git a/ld/testsuite/ld-i386/property-4.r b/ld/testsuite/ld-i386/property-4.r
index 876d05708f..83b4086481 100644
--- a/ld/testsuite/ld-i386/property-4.r
+++ b/ld/testsuite/ld-i386/property-4.r
@@ -3,5 +3,6 @@ Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
Properties: stack size: 0x800000
+#...
x86 ISA needed: CMOV, SSE, SSE3
#pass
diff --git a/ld/testsuite/ld-i386/property-5.r b/ld/testsuite/ld-i386/property-5.r
index adef5e8db2..0bc8e8dea7 100644
--- a/ld/testsuite/ld-i386/property-5.r
+++ b/ld/testsuite/ld-i386/property-5.r
@@ -3,5 +3,6 @@ Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
Properties: stack size: 0x900000
+#...
x86 ISA needed: CMOV, SSE, SSE3
#pass
diff --git a/ld/testsuite/ld-i386/property-x86-ibt1a.d b/ld/testsuite/ld-i386/property-x86-ibt1a.d
index 5350f74ca5..1b9efd31b6 100644
--- a/ld/testsuite/ld-i386/property-x86-ibt1a.d
+++ b/ld/testsuite/ld-i386/property-x86-ibt1a.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000018 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86
diff --git a/ld/testsuite/ld-i386/property-x86-ibt1b.d b/ld/testsuite/ld-i386/property-x86-ibt1b.d
index d658c5dc89..66ad0b70fc 100644
--- a/ld/testsuite/ld-i386/property-x86-ibt1b.d
+++ b/ld/testsuite/ld-i386/property-x86-ibt1b.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000018 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86
diff --git a/ld/testsuite/ld-i386/property-x86-shstk1a.d b/ld/testsuite/ld-i386/property-x86-shstk1a.d
index 3fd91085fe..b8da25ac9d 100644
--- a/ld/testsuite/ld-i386/property-x86-shstk1a.d
+++ b/ld/testsuite/ld-i386/property-x86-shstk1a.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000018 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86
diff --git a/ld/testsuite/ld-i386/property-x86-shstk1b.d b/ld/testsuite/ld-i386/property-x86-shstk1b.d
index 28796c9a62..bc962ec821 100644
--- a/ld/testsuite/ld-i386/property-x86-shstk1b.d
+++ b/ld/testsuite/ld-i386/property-x86-shstk1b.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000018 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86
diff --git a/ld/testsuite/ld-x86-64/ibt-plt-2a-x32.d b/ld/testsuite/ld-x86-64/ibt-plt-2a-x32.d
index 70585634bf..b91b1e6ac9 100644
--- a/ld/testsuite/ld-x86-64/ibt-plt-2a-x32.d
+++ b/ld/testsuite/ld-x86-64/ibt-plt-2a-x32.d
@@ -8,36 +8,36 @@

Disassembly of section .plt:

-0+140 <.plt>:
- +[a-f0-9]+: ff 35 4a 01 20 00 pushq 0x20014a\(%rip\) # 200290 <_GLOBAL_OFFSET_TABLE_\+0x8>
- +[a-f0-9]+: ff 25 4c 01 20 00 jmpq \*0x20014c\(%rip\) # 200298 <_GLOBAL_OFFSET_TABLE_\+0x10>
+[a-f0-9]+ <.plt>:
+ +[a-f0-9]+: ff 35 ([0-9a-f]{2} ){4}[ ]+pushq 0x[a-f0-9]+\(%rip\) # [a-f0-9]+ <_GLOBAL_OFFSET_TABLE_\+0x8>
+ +[a-f0-9]+: ff 25 ([0-9a-f]{2} ){4}[ ]+jmpq \*0x[a-f0-9]+\(%rip\) # [a-f0-9]+ <_GLOBAL_OFFSET_TABLE_\+0x10>
+[a-f0-9]+: 0f 1f 40 00 nopl 0x0\(%rax\)
+[a-f0-9]+: f3 0f 1e fa endbr64
+[a-f0-9]+: 68 00 00 00 00 pushq \$0x0
- +[a-f0-9]+: e9 e2 ff ff ff jmpq 140 <.plt>
+ +[a-f0-9]+: e9 e2 ff ff ff jmpq [a-f0-9]+ <.plt>
+[a-f0-9]+: 66 90 xchg %ax,%ax
+[a-f0-9]+: f3 0f 1e fa endbr64
+[a-f0-9]+: 68 01 00 00 00 pushq \$0x1
- +[a-f0-9]+: e9 d2 ff ff ff jmpq 140 <.plt>
+ +[a-f0-9]+: e9 d2 ff ff ff jmpq [a-f0-9]+ <.plt>
+[a-f0-9]+: 66 90 xchg %ax,%ax

Disassembly of section .plt.sec:

-0+170 <***@plt>:
+[a-f0-9]+ <***@plt>:
+[a-f0-9]+: f3 0f 1e fa endbr64
- +[a-f0-9]+: ff 25 26 01 20 00 jmpq \*0x200126\(%rip\) # 2002a0 <bar1>
+ +[a-f0-9]+: ff 25 ([0-9a-f]{2} ){4}[ ]+jmpq \*0x[a-f0-9]+\(%rip\) # [a-f0-9]+ <bar1>
+[a-f0-9]+: 66 0f 1f 44 00 00 nopw 0x0\(%rax,%rax,1\)

-0+180 <***@plt>:
+[a-f0-9]+ <***@plt>:
+[a-f0-9]+: f3 0f 1e fa endbr64
- +[a-f0-9]+: ff 25 1e 01 20 00 jmpq \*0x20011e\(%rip\) # 2002a8 <bar2>
+ +[a-f0-9]+: ff 25 ([0-9a-f]{2} ){4}[ ]+jmpq \*0x[a-f0-9]+\(%rip\) # [a-f0-9]+ <bar2>
+[a-f0-9]+: 66 0f 1f 44 00 00 nopw 0x0\(%rax,%rax,1\)

Disassembly of section .text:

-0+190 <foo>:
+[a-f0-9]+ <foo>:
+[a-f0-9]+: 48 83 ec 08 sub \$0x8,%rsp
- +[a-f0-9]+: e8 e7 ff ff ff callq 180 <***@plt>
+ +[a-f0-9]+: e8 e7 ff ff ff callq [a-f0-9]+ <***@plt>
+[a-f0-9]+: 48 83 c4 08 add \$0x8,%rsp
- +[a-f0-9]+: e9 ce ff ff ff jmpq 170 <***@plt>
+ +[a-f0-9]+: e9 ce ff ff ff jmpq [a-f0-9]+ <***@plt>
#pass
diff --git a/ld/testsuite/ld-x86-64/ibt-plt-2a.d b/ld/testsuite/ld-x86-64/ibt-plt-2a.d
index 0894354026..3c5d582432 100644
--- a/ld/testsuite/ld-x86-64/ibt-plt-2a.d
+++ b/ld/testsuite/ld-x86-64/ibt-plt-2a.d
@@ -8,36 +8,36 @@

Disassembly of section .plt:

-0+1f0 <.plt>:
- +[a-f0-9]+: ff 35 ca 01 20 00 pushq 0x2001ca\(%rip\) # 2003c0 <_GLOBAL_OFFSET_TABLE_\+0x8>
- +[a-f0-9]+: f2 ff 25 cb 01 20 00 bnd jmpq \*0x2001cb\(%rip\) # 2003c8 <_GLOBAL_OFFSET_TABLE_\+0x10>
+[a-f0-9]+ <.plt>:
+ +[a-f0-9]+: ff 35 ([0-9a-f]{2} ){4}[ ]+pushq 0x[a-f0-9]+\(%rip\) # [a-f0-9]+ <_GLOBAL_OFFSET_TABLE_\+0x8>
+ +[a-f0-9]+: f2 ff 25 ([0-9a-f]{2} ){4}[ ]+bnd jmpq \*0x[a-f0-9]+\(%rip\) # [a-f0-9]+ <_GLOBAL_OFFSET_TABLE_\+0x10>
+[a-f0-9]+: 0f 1f 00 nopl \(%rax\)
+[a-f0-9]+: f3 0f 1e fa endbr64
+[a-f0-9]+: 68 00 00 00 00 pushq \$0x0
- +[a-f0-9]+: f2 e9 e1 ff ff ff bnd jmpq 1f0 <.plt>
+ +[a-f0-9]+: f2 e9 e1 ff ff ff bnd jmpq [a-f0-9]+ <.plt>
+[a-f0-9]+: 90 nop
+[a-f0-9]+: f3 0f 1e fa endbr64
+[a-f0-9]+: 68 01 00 00 00 pushq \$0x1
- +[a-f0-9]+: f2 e9 d1 ff ff ff bnd jmpq 1f0 <.plt>
+ +[a-f0-9]+: f2 e9 d1 ff ff ff bnd jmpq [a-f0-9]+ <.plt>
+[a-f0-9]+: 90 nop

Disassembly of section .plt.sec:

-0+220 <***@plt>:
+[a-f0-9]+ <***@plt>:
+[a-f0-9]+: f3 0f 1e fa endbr64
- +[a-f0-9]+: f2 ff 25 a5 01 20 00 bnd jmpq \*0x2001a5\(%rip\) # 2003d0 <bar1>
+ +[a-f0-9]+: f2 ff 25 ([0-9a-f]{2} ){4}[ ]+bnd jmpq \*0x[a-f0-9]+\(%rip\) # [a-f0-9]+ <bar1>
+[a-f0-9]+: 0f 1f 44 00 00 nopl 0x0\(%rax,%rax,1\)

-0+230 <***@plt>:
+[a-f0-9]+ <***@plt>:
+[a-f0-9]+: f3 0f 1e fa endbr64
- +[a-f0-9]+: f2 ff 25 9d 01 20 00 bnd jmpq \*0x20019d\(%rip\) # 2003d8 <bar2>
+ +[a-f0-9]+: f2 ff 25 ([0-9a-f]{2} ){4}[ ]+bnd jmpq \*0x[a-f0-9]+\(%rip\) # [a-f0-9]+ <bar2>
+[a-f0-9]+: 0f 1f 44 00 00 nopl 0x0\(%rax,%rax,1\)

Disassembly of section .text:

-0+240 <foo>:
+[a-f0-9]+ <foo>:
+[a-f0-9]+: 48 83 ec 08 sub \$0x8,%rsp
- +[a-f0-9]+: e8 e7 ff ff ff callq 230 <***@plt>
+ +[a-f0-9]+: e8 e7 ff ff ff callq [a-f0-9]+ <***@plt>
+[a-f0-9]+: 48 83 c4 08 add \$0x8,%rsp
- +[a-f0-9]+: e9 ce ff ff ff jmpq 220 <***@plt>
+ +[a-f0-9]+: e9 ce ff ff ff jmpq [a-f0-9]+ <***@plt>
#pass
diff --git a/ld/testsuite/ld-x86-64/ibt-plt-2b-x32.d b/ld/testsuite/ld-x86-64/ibt-plt-2b-x32.d
index 2f7505a70d..0674d2078f 100644
--- a/ld/testsuite/ld-x86-64/ibt-plt-2b-x32.d
+++ b/ld/testsuite/ld-x86-64/ibt-plt-2b-x32.d
@@ -18,21 +18,26 @@ Contents of the .eh_frame section:
DW_CFA_nop
DW_CFA_nop

-0+18 00000014 0000001c FDE cie=00000000 pc=00000190..000001a2
- DW_CFA_advance_loc: 4 to 00000194
+0+18 00000014 0000001c FDE cie=00000000 pc=[a-f0-9]+\.\.[a-f0-9]+
+ DW_CFA_advance_loc: 4 to [a-f0-9]+
DW_CFA_def_cfa_offset: 16
- DW_CFA_advance_loc: 9 to 0000019d
+ DW_CFA_advance_loc: 9 to [a-f0-9]+
DW_CFA_def_cfa_offset: 8
DW_CFA_nop

-0+30 00000020 00000034 FDE cie=00000000 pc=00000140..00000170
+0+30 00000020 00000034 FDE cie=00000000 pc=[a-f0-9]+\.\.[a-f0-9]+
DW_CFA_def_cfa_offset: 16
- DW_CFA_advance_loc: 6 to 00000146
+ DW_CFA_advance_loc: 6 to [a-f0-9]+
DW_CFA_def_cfa_offset: 24
- DW_CFA_advance_loc: 10 to 00000150
+ DW_CFA_advance_loc: 10 to [a-f0-9]+
DW_CFA_def_cfa_expression \(DW_OP_breg7 \(rsp\): 8; DW_OP_breg16 \(rip\): 0; DW_OP_lit15; DW_OP_and; DW_OP_lit9; DW_OP_ge; DW_OP_lit3; DW_OP_shl; DW_OP_plus\)

-0+54 00000010 00000058 FDE cie=00000000 pc=00000170..00000190
+0+54 00000010 00000058 FDE cie=00000000 pc=[a-f0-9]+\.\.[a-f0-9]+
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature: <None>
diff --git a/ld/testsuite/ld-x86-64/ibt-plt-2b.d b/ld/testsuite/ld-x86-64/ibt-plt-2b.d
index 2bb59d0d83..e10f9a26f3 100644
--- a/ld/testsuite/ld-x86-64/ibt-plt-2b.d
+++ b/ld/testsuite/ld-x86-64/ibt-plt-2b.d
@@ -18,25 +18,30 @@ Contents of the .eh_frame section:
DW_CFA_nop
DW_CFA_nop

-0+18 0000000000000014 0000001c FDE cie=00000000 pc=0000000000000240..0000000000000252
- DW_CFA_advance_loc: 4 to 0000000000000244
+0+18 0000000000000014 0000001c FDE cie=00000000 pc=[a-f0-9]+\.\.[a-f0-9]+
+ DW_CFA_advance_loc: 4 to [a-f0-9]+
DW_CFA_def_cfa_offset: 16
- DW_CFA_advance_loc: 9 to 000000000000024d
+ DW_CFA_advance_loc: 9 to [a-f0-9]+
DW_CFA_def_cfa_offset: 8
DW_CFA_nop

-0+30 0000000000000024 00000034 FDE cie=00000000 pc=00000000000001f0..0000000000000220
+0+30 0000000000000024 00000034 FDE cie=00000000 pc=[a-f0-9]+\.\.[a-f0-9]+
DW_CFA_def_cfa_offset: 16
- DW_CFA_advance_loc: 6 to 00000000000001f6
+ DW_CFA_advance_loc: 6 to [a-f0-9]+
DW_CFA_def_cfa_offset: 24
- DW_CFA_advance_loc: 10 to 0000000000000200
+ DW_CFA_advance_loc: 10 to [a-f0-9]+
DW_CFA_def_cfa_expression \(DW_OP_breg7 \(rsp\): 8; DW_OP_breg16 \(rip\): 0; DW_OP_lit15; DW_OP_and; DW_OP_lit10; DW_OP_ge; DW_OP_lit3; DW_OP_shl; DW_OP_plus\)
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop

-0+58 0000000000000010 0000005c FDE cie=00000000 pc=0000000000000220..0000000000000240
+0+58 0000000000000010 0000005c FDE cie=00000000 pc=[a-f0-9]+\.\.[a-f0-9]+
DW_CFA_nop
DW_CFA_nop
DW_CFA_nop
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature: <None>
diff --git a/ld/testsuite/ld-x86-64/pr23372a-x32.d b/ld/testsuite/ld-x86-64/pr23372a-x32.d
index 9f93642364..84e4602994 100644
--- a/ld/testsuite/ld-x86-64/pr23372a-x32.d
+++ b/ld/testsuite/ld-x86-64/pr23372a-x32.d
@@ -3,3 +3,8 @@
#as: --x32
#ld: -r -m elf32_x86_64
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA used:
diff --git a/ld/testsuite/ld-x86-64/pr23372a.d b/ld/testsuite/ld-x86-64/pr23372a.d
index ee688fc2e2..d988a6a4cb 100644
--- a/ld/testsuite/ld-x86-64/pr23372a.d
+++ b/ld/testsuite/ld-x86-64/pr23372a.d
@@ -3,3 +3,8 @@
#as: --64 -defsym __64_bit__=1
#ld: -r -m elf_x86_64
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA used:
diff --git a/ld/testsuite/ld-x86-64/pr23372b-x32.d b/ld/testsuite/ld-x86-64/pr23372b-x32.d
index 5b0cf98618..65cf228cc3 100644
--- a/ld/testsuite/ld-x86-64/pr23372b-x32.d
+++ b/ld/testsuite/ld-x86-64/pr23372b-x32.d
@@ -3,3 +3,8 @@
#as: --x32
#ld: -r -m elf32_x86_64
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA needed:
diff --git a/ld/testsuite/ld-x86-64/pr23372b.d b/ld/testsuite/ld-x86-64/pr23372b.d
index 727afa8ab5..57c0220f56 100644
--- a/ld/testsuite/ld-x86-64/pr23372b.d
+++ b/ld/testsuite/ld-x86-64/pr23372b.d
@@ -3,3 +3,8 @@
#as: --64 -defsym __64_bit__=1
#ld: -r -m elf_x86_64
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA needed:
diff --git a/ld/testsuite/ld-x86-64/pr23372c-x32.d b/ld/testsuite/ld-x86-64/pr23372c-x32.d
index 863f4b7e44..efd6e84aa2 100644
--- a/ld/testsuite/ld-x86-64/pr23372c-x32.d
+++ b/ld/testsuite/ld-x86-64/pr23372c-x32.d
@@ -3,3 +3,8 @@
#as: --x32
#ld: -r -m elf32_x86_64
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA used:
diff --git a/ld/testsuite/ld-x86-64/pr23372c.d b/ld/testsuite/ld-x86-64/pr23372c.d
index 23bdaa786a..f56859a014 100644
--- a/ld/testsuite/ld-x86-64/pr23372c.d
+++ b/ld/testsuite/ld-x86-64/pr23372c.d
@@ -3,3 +3,8 @@
#as: --64 -defsym __64_bit__=1
#ld: -r -m elf_x86_64
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA used:
diff --git a/ld/testsuite/ld-x86-64/pr23372d-x32.d b/ld/testsuite/ld-x86-64/pr23372d-x32.d
index 80c783dff7..daaaf4eea3 100644
--- a/ld/testsuite/ld-x86-64/pr23372d-x32.d
+++ b/ld/testsuite/ld-x86-64/pr23372d-x32.d
@@ -3,3 +3,8 @@
#as: --x32
#ld: -r -m elf32_x86_64
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA needed:
diff --git a/ld/testsuite/ld-x86-64/pr23372d.d b/ld/testsuite/ld-x86-64/pr23372d.d
index 355269827b..8f6a171648 100644
--- a/ld/testsuite/ld-x86-64/pr23372d.d
+++ b/ld/testsuite/ld-x86-64/pr23372d.d
@@ -3,3 +3,8 @@
#as: --64 -defsym __64_bit__=1
#ld: -r -m elf_x86_64
#readelf: -n
+
+Displaying notes found in: .note.gnu.property
+ Owner Data size Description
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 ISA needed:
diff --git a/ld/testsuite/ld-x86-64/property-3.r b/ld/testsuite/ld-x86-64/property-3.r
index e9f7162357..b4f9976c56 100644
--- a/ld/testsuite/ld-x86-64/property-3.r
+++ b/ld/testsuite/ld-x86-64/property-3.r
@@ -3,5 +3,6 @@ Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
Properties: stack size: 0x800000
+#...
x86 ISA needed: CMOV, SSE
#pass
diff --git a/ld/testsuite/ld-x86-64/property-4.r b/ld/testsuite/ld-x86-64/property-4.r
index 876d05708f..83b4086481 100644
--- a/ld/testsuite/ld-x86-64/property-4.r
+++ b/ld/testsuite/ld-x86-64/property-4.r
@@ -3,5 +3,6 @@ Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
Properties: stack size: 0x800000
+#...
x86 ISA needed: CMOV, SSE, SSE3
#pass
diff --git a/ld/testsuite/ld-x86-64/property-5.r b/ld/testsuite/ld-x86-64/property-5.r
index adef5e8db2..0bc8e8dea7 100644
--- a/ld/testsuite/ld-x86-64/property-5.r
+++ b/ld/testsuite/ld-x86-64/property-5.r
@@ -3,5 +3,6 @@ Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
Properties: stack size: 0x900000
+#...
x86 ISA needed: CMOV, SSE, SSE3
#pass
diff --git a/ld/testsuite/ld-x86-64/property-x86-ibt1a-x32.d b/ld/testsuite/ld-x86-64/property-x86-ibt1a-x32.d
index 7a95401ac3..ee692f5819 100644
--- a/ld/testsuite/ld-x86-64/property-x86-ibt1a-x32.d
+++ b/ld/testsuite/ld-x86-64/property-x86-ibt1a-x32.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000018 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86
diff --git a/ld/testsuite/ld-x86-64/property-x86-ibt1a.d b/ld/testsuite/ld-x86-64/property-x86-ibt1a.d
index e989a8a817..f269d569f6 100644
--- a/ld/testsuite/ld-x86-64/property-x86-ibt1a.d
+++ b/ld/testsuite/ld-x86-64/property-x86-ibt1a.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86
diff --git a/ld/testsuite/ld-x86-64/property-x86-ibt1b-x32.d b/ld/testsuite/ld-x86-64/property-x86-ibt1b-x32.d
index 302db4a35b..ab16ef3416 100644
--- a/ld/testsuite/ld-x86-64/property-x86-ibt1b-x32.d
+++ b/ld/testsuite/ld-x86-64/property-x86-ibt1b-x32.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000018 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86
diff --git a/ld/testsuite/ld-x86-64/property-x86-ibt1b.d b/ld/testsuite/ld-x86-64/property-x86-ibt1b.d
index 6c4e67d865..1d589106e4 100644
--- a/ld/testsuite/ld-x86-64/property-x86-ibt1b.d
+++ b/ld/testsuite/ld-x86-64/property-x86-ibt1b.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86
diff --git a/ld/testsuite/ld-x86-64/property-x86-shstk1a-x32.d b/ld/testsuite/ld-x86-64/property-x86-shstk1a-x32.d
index 682ec6478a..93c8b1be67 100644
--- a/ld/testsuite/ld-x86-64/property-x86-shstk1a-x32.d
+++ b/ld/testsuite/ld-x86-64/property-x86-shstk1a-x32.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000018 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86
diff --git a/ld/testsuite/ld-x86-64/property-x86-shstk1a.d b/ld/testsuite/ld-x86-64/property-x86-shstk1a.d
index 7a14862296..dfb6ef3897 100644
--- a/ld/testsuite/ld-x86-64/property-x86-shstk1a.d
+++ b/ld/testsuite/ld-x86-64/property-x86-shstk1a.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86
diff --git a/ld/testsuite/ld-x86-64/property-x86-shstk1b-x32.d b/ld/testsuite/ld-x86-64/property-x86-shstk1b-x32.d
index f36edc76f7..afed8d4865 100644
--- a/ld/testsuite/ld-x86-64/property-x86-shstk1b-x32.d
+++ b/ld/testsuite/ld-x86-64/property-x86-shstk1b-x32.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000018 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86
diff --git a/ld/testsuite/ld-x86-64/property-x86-shstk1b.d b/ld/testsuite/ld-x86-64/property-x86-shstk1b.d
index 1067547e33..054e712e19 100644
--- a/ld/testsuite/ld-x86-64/property-x86-shstk1b.d
+++ b/ld/testsuite/ld-x86-64/property-x86-shstk1b.d
@@ -6,6 +6,7 @@

Displaying notes found in: .note.gnu.property
Owner Data size Description
- GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
- Properties: x86 ISA used: <None>
+ GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0
+ Properties: x86 feature:
+ x86 ISA used: <None>
x86 feature used: x86

[H.J. Lu]

Post by H.J. Lu
Since empty x86 properties contain valid information, they shouldn't be
removed.

Where is this documented? How is a property consisting of all zeroes
different from a missing property?
(I understand the difference for ISA_1_USED in relocatable objects --
an input object missing this property kills the property for the
output file -- but I can't find anything that says under what
circumstances the output property section should contain a property
with all zeroes.)

GNU_PROPERTY_X86_ISA_1_USED bits can be all zero when only
base x86 instructions are used. Linker shouldn't remove properties
with zero bits.

[Cary Coutant]

Post by H.J. Lu

Post by H.J. Lu
Since empty x86 properties contain valid information, they shouldn't be
removed.

Where is this documented? How is a property consisting of all zeroes
different from a missing property?
(I understand the difference for ISA_1_USED in relocatable objects --
an input object missing this property kills the property for the
output file -- but I can't find anything that says under what
circumstances the output property section should contain a property
with all zeroes.)

GNU_PROPERTY_X86_ISA_1_USED bits can be all zero when only
base x86 instructions are used. Linker shouldn't remove properties
with zero bits.

Where is this documented? How is a property consisting of all zeroes
different from a missing property?

-cary

[Cary Coutant]

Post by H.J. Lu
GNU_PROPERTY_X86_ISA_1_USED bits can be all zero when only
base x86 instructions are used. Linker shouldn't remove properties
with zero bits.
To me this is a confusing message. How about simply saying "Removed
property 0xc0000002 in foo.o (0x1)", and similarly for the other
messages where properties are removed. If ld is removing them then it
isn't merging them.

This misses the crucial info that property 0xc0000002 is removed due to
bar.o (None).

You still haven't explained the difference between a missing property
and one that is all zeroes. Do you *really* think it's a good idea to
make a distinction?

Post by H.J. Lu

Where is this documented? How is a property consisting of all zeroes
different from a missing property?

-cary

[H.J. Lu]

Post by Cary Coutant

Post by H.J. Lu
GNU_PROPERTY_X86_ISA_1_USED bits can be all zero when only
base x86 instructions are used. Linker shouldn't remove properties
with zero bits.

It will be updated.

Post by Cary Coutant

Post by H.J. Lu
To me this is a confusing message. How about simply saying "Removed
property 0xc0000002 in foo.o (0x1)", and similarly for the other
messages where properties are removed. If ld is removing them then it
isn't merging them.

This misses the crucial info that property 0xc0000002 is removed due to
bar.o (None).

You still haven't explained the difference between a missing property
and one that is all zeroes. Do you *really* think it's a good idea to
make a distinction?

How about this

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.

[Cary Coutant]

Post by H.J. Lu
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.

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"?

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.

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.

-cary

[H.J. Lu]

Post by Cary Coutant

Post by H.J. Lu
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.

Post by Cary Coutant
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.

Post by Cary Coutant
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.

Post by Cary Coutant
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.

[Cary Coutant]

Post by H.J. Lu
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.

You can tell if none of the input relocatables have the feature only
if *all* of the input relocatables have the property. If even one of
the input relocatables is missing the property, you lose all the
feature bits -- you're discarding potentially useful information.
Remember, all the 1 bits are trustworthy even if a relocatable is
missing the property; it's the 0 bits that might not be accurate
(i.e., some of them might have been 1, depending on features used by
the objects missing the property info).

So now what do you expect the loader to do with the information in the
property note? If you have feature bits, presumably it will compare
the 1 bits with the available features on the hardware, and refuse to
run the program if its demands exceed the available features. And it
could give a meaningful error message explaining exactly which
features are required but not available.

But what if you've removed the property entirely? Should the loader
refuse to run the program? No, you're going to want it to run anyway,
right? And it'll fail at run time if it tries to use an unavailable
feature. But if you hadn't thrown away those 1 bits, you could still
get a meaningful error message for the features we do know about. A
single new AND bit (or a version number) will tell you the same thing
that a missing property tells you, without throwing away all those
useful bits of information.

-cary

[H.J. Lu]

Post by Cary Coutant

Post by H.J. Lu
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.

You can tell if none of the input relocatables have the feature only
if *all* of the input relocatables have the property. If even one of
the input relocatables is missing the property, you lose all the
feature bits -- you're discarding potentially useful information.
Remember, all the 1 bits are trustworthy even if a relocatable is
missing the property; it's the 0 bits that might not be accurate
(i.e., some of them might have been 1, depending on features used by
the objects missing the property info).

1 bits are accurate for AND, OR and OR_AND. 0 bits are accurate only
for OR_AND.

Post by Cary Coutant
So now what do you expect the loader to do with the information in the
property note? If you have feature bits, presumably it will compare
the 1 bits with the available features on the hardware, and refuse to
run the program if its demands exceed the available features. And it
could give a meaningful error message explaining exactly which
features are required but not available.

Correct.

Post by Cary Coutant
But what if you've removed the property entirely? Should the loader
refuse to run the program? No, you're going to want it to run anyway,
right? And it'll fail at run time if it tries to use an unavailable
feature. But if you hadn't thrown away those 1 bits, you could still
get a meaningful error message for the features we do know about. A
single new AND bit (or a version number) will tell you the same thing
that a missing property tells you, without throwing away all those
useful bits of information.

AND and OR_AND are used for different purposes:

1. AND: It is OK if run-time doesn't have the feature the program supports,
like CET.
2. OR_AND: It is not OK if run-time doesn't have the feature the program
requires, like needed AVX512

OR is informational, like used AVX512:

1 bit: Yes.
0 bit: Unknown.

AND and OR_AND are useful for loaders and must be originated by
compiler or programmer. OR may be generated automatically by
assembler.

[H.J. Lu]

Post by H.J. Lu

Post by Cary Coutant

Post by H.J. Lu
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.

You can tell if none of the input relocatables have the feature only
if *all* of the input relocatables have the property. If even one of
the input relocatables is missing the property, you lose all the
feature bits -- you're discarding potentially useful information.
Remember, all the 1 bits are trustworthy even if a relocatable is
missing the property; it's the 0 bits that might not be accurate
(i.e., some of them might have been 1, depending on features used by
the objects missing the property info).

1 bits are accurate for AND, OR and OR_AND. 0 bits are accurate only
for OR_AND.

Post by Cary Coutant
So now what do you expect the loader to do with the information in the
property note? If you have feature bits, presumably it will compare
the 1 bits with the available features on the hardware, and refuse to
run the program if its demands exceed the available features. And it
could give a meaningful error message explaining exactly which
features are required but not available.

Correct.

Post by Cary Coutant
But what if you've removed the property entirely? Should the loader
refuse to run the program? No, you're going to want it to run anyway,
right? And it'll fail at run time if it tries to use an unavailable
feature. But if you hadn't thrown away those 1 bits, you could still
get a meaningful error message for the features we do know about. A
single new AND bit (or a version number) will tell you the same thing
that a missing property tells you, without throwing away all those
useful bits of information.

1. AND: It is OK if run-time doesn't have the feature the program supports,
like CET.
2. OR_AND: It is not OK if run-time doesn't have the feature the program
requires, like needed AVX512
1 bit: Yes.
0 bit: Unknown.
AND and OR_AND are useful for loaders and must be originated by
compiler or programmer. OR may be generated automatically by
assembler.

I pushed the following changes into hjl/property branch:

commit aa4e331977fd0b39ffef0cf65fae9d3241659cf5
Author: H.J. Lu <***@gmail.com>
Date: Wed Nov 28 08:47:44 2018 -0800

Update GNU_PROPERTY_X86_ISA_1_USED

commit c2c5e7d7c3a0c56cacb2d49898686a3584ff4e77
Author: H.J. Lu <***@gmail.com>
Date: Tue Nov 27 13:36:10 2018 -0800

Update GNU_PROPERTY_X86_XXX
commit d919c05ffef8f40cb7de82a71658dbcce2ef5907
Author: H.J. Lu <***@gmail.com>
Date: Tue Nov 27 11:49:21 2018 -0800

Remove GNU_PROPERTY_X86_UINT32_VALID

The updated x86-64 psABI pdf is at

https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-property.pdf

[Cary Coutant]

Post by H.J. Lu
1. AND: It is OK if run-time doesn't have the feature the program supports,
like CET.
2. OR_AND: It is not OK if run-time doesn't have the feature the program
requires, like needed AVX512
1 bit: Yes.
0 bit: Unknown.
AND and OR_AND are useful for loaders and must be originated by
compiler or programmer. OR may be generated automatically by
assembler.

Isn't this the opposite of what you have in the psABI?

GNU_PROPERTY_X86_FEATURE_2_USED [which is OR_AND] The x86
processor features indicated by the corresponding bits are
used in program. Their support in the hardware is optional.
Its absence in an x86 ELF binary implies that any x86
processor features may be used.

GNU_PROPERTY_X86_FEATURE_2_NEEDED [which is OR] The x86
processor features indicated by the corresponding bits are
used in program and they must be supported by the hardware.

What you've written in your email makes more sense, which suggests
that you've got the values for the USED and NEEDED properties reversed
in the psABI.

But the point I've been trying to make is that your OR_AND rule is
needlessly coarse-grained -- if any input object is missing a property
note, you discard information about features that we can know are
needed. Let's take a high-level look at what we're trying to track...

The NEEDED properties that indicate what hardware features are needed
for execution (what should be OR_AND in your scheme) are conceptually
tri-state properties for each feature:

NO: the program does not need this feature
YES: the program does need this feature
UNK: it is unknown because one or more objects didn't specify

If we were to keep track of the state of each individual feature, we'd
want to combine states as follows:

NO + NO -> NO
UNK + NO -> UNK
UNK + UNK -> UNK
YES + X -> YES

One way to track the state for each property individually would be to
use two separate bit masks: FEATURE_X_KNOWN and FEATURE_X_NEEDED. The
KNOWN properties would use the AND combining rule, and the NEEDED
properties would use the OR combining rule. The various combinations
would have the following meanings:

K = 0 & N = 0: UNK
K = 1 & N = 0: NO (not needed)
K = X & N = 1: YES (needed)

(where K and N are the corresponding bits for any specific feature
from FEATURE_X_KNOWN and FEATURE_X_NEEDED, respectively).

This would let the linker keep track of the state of each individual
property, and the loader could correctly refuse to run a program that
needs an unavailable feature even if one or more input objects lack
the property notes. A missing property note would force all the NOs to
UNKs, but would leave the YESes alone.

Also, in this scheme (as with my earlier suggestions of using a single
FEATURE_1_AND bit or a version number), a missing property always
means the same as a property with all zeroes.

With your approach, where you represent the UNK state by a missing
property, any missing property note forces *all* features to the UNK
state, even if we can state for sure that a feature is needed.

-cary

[H.J. Lu]

Post by Cary Coutant

Post by H.J. Lu
1. AND: It is OK if run-time doesn't have the feature the program supports,
like CET.
2. OR_AND: It is not OK if run-time doesn't have the feature the program
requires, like needed AVX512
1 bit: Yes.
0 bit: Unknown.
AND and OR_AND are useful for loaders and must be originated by
compiler or programmer. OR may be generated automatically by
assembler.

Isn't this the opposite of what you have in the psABI?
GNU_PROPERTY_X86_FEATURE_2_USED [which is OR_AND] The x86
processor features indicated by the corresponding bits are
used in program. Their support in the hardware is optional.
Its absence in an x86 ELF binary implies that any x86
processor features may be used.
GNU_PROPERTY_X86_FEATURE_2_NEEDED [which is OR] The x86
processor features indicated by the corresponding bits are
used in program and they must be supported by the hardware.
What you've written in your email makes more sense, which suggests
that you've got the values for the USED and NEEDED properties reversed
in the psABI.
But the point I've been trying to make is that your OR_AND rule is
needlessly coarse-grained -- if any input object is missing a property
note, you discard information about features that we can know are
needed. Let's take a high-level look at what we're trying to track...
The NEEDED properties that indicate what hardware features are needed
for execution (what should be OR_AND in your scheme) are conceptually
NO: the program does not need this feature
YES: the program does need this feature
UNK: it is unknown because one or more objects didn't specify
If we were to keep track of the state of each individual feature, we'd
NO + NO -> NO
UNK + NO -> UNK
UNK + UNK -> UNK
YES + X -> YES
One way to track the state for each property individually would be to
use two separate bit masks: FEATURE_X_KNOWN and FEATURE_X_NEEDED. The
KNOWN properties would use the AND combining rule, and the NEEDED
properties would use the OR combining rule. The various combinations
K = 0 & N = 0: UNK
K = 1 & N = 0: NO (not needed)
K = X & N = 1: YES (needed)
(where K and N are the corresponding bits for any specific feature
from FEATURE_X_KNOWN and FEATURE_X_NEEDED, respectively).
This would let the linker keep track of the state of each individual
property, and the loader could correctly refuse to run a program that
needs an unavailable feature even if one or more input objects lack
the property notes. A missing property note would force all the NOs to
UNKs, but would leave the YESes alone.
Also, in this scheme (as with my earlier suggestions of using a single
FEATURE_1_AND bit or a version number), a missing property always
means the same as a property with all zeroes.
With your approach, where you represent the UNK state by a missing
property, any missing property note forces *all* features to the UNK
state, even if we can state for sure that a feature is needed.

Here are what I have on my machine:

[***@gnu-cfl-2 compilers]$ readelf -n /lib64/ld-linux-x86-64.so.2 | head

Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000030 NT_GNU_PROPERTY_TYPE_0
Properties: x86 feature: IBT, SHSTK
x86 ISA used: CMOV, SSE, SSE2, AVX, AVX512F
x86 feature used: x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC

x86 feature: IBT, SHSTK

is AND/GNU_PROPERTY_X86_FEATURE_1_AND. It is generated
by GCC with -fcf-protection.

x86 ISA used: CMOV, SSE, SSE2, AVX, AVX512F

is OR_AND/GNU_PROPERTY_X86_ISA_1_USED. It is generated by
assembler with -mx86-used-note=yes.

x86 feature used: x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC

is OR_AND/GNU_PROPERTY_X86_FEATURE_2_USED. It is generated
by assembler with -mx86-used-note=yes.

They tell

1. The binary supports IBT and SHSTK.
2. The binary only uses base ISA + CMOV, SSE, SSE2, AVX, AVX512F.
3 The binary only uses x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC.

If someone wants to create a set of binaries for AVX2 and above. He/she
can set AVX2 in OR/GNU_PROPERTY_X86_ISA_1_NEEDED and XMM/YMM
in OR/GNU_PROPERTY_X86_FEATURE_2_NEEDED.

How can I achieve the above with your suggestion?

[Cary Coutant]

Post by H.J. Lu
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000030 NT_GNU_PROPERTY_TYPE_0
Properties: x86 feature: IBT, SHSTK
x86 ISA used: CMOV, SSE, SSE2, AVX, AVX512F
x86 feature used: x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC
x86 feature: IBT, SHSTK
is AND/GNU_PROPERTY_X86_FEATURE_1_AND. It is generated
by GCC with -fcf-protection.
x86 ISA used: CMOV, SSE, SSE2, AVX, AVX512F
is OR_AND/GNU_PROPERTY_X86_ISA_1_USED. It is generated by
assembler with -mx86-used-note=yes.
x86 feature used: x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC
is OR_AND/GNU_PROPERTY_X86_FEATURE_2_USED. It is generated
by assembler with -mx86-used-note=yes.
They tell
1. The binary supports IBT and SHSTK.
2. The binary only uses base ISA + CMOV, SSE, SSE2, AVX, AVX512F.
3 The binary only uses x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC.
If someone wants to create a set of binaries for AVX2 and above. He/she
can set AVX2 in OR/GNU_PROPERTY_X86_ISA_1_NEEDED and XMM/YMM
in OR/GNU_PROPERTY_X86_FEATURE_2_NEEDED.
How can I achieve the above with your suggestion?

Before I answer that, let's talk about "NEEDED" vs. "USED".

In the psABI, you have described both ISA_1_USED and FEATURE_2_USED as
"their support in the hardware is optional". Yet:

(a) You've assigned values for both of these in the OR_AND range,
which you've described earlier in this thread as meaning "It is not OK
if run-time doesn't have the feature the program requires."

(b) Your example from ld-linux-x86-64.so.2 shows ISA_1_USED and
FEATURE_2_USED, but does not use either "NEEDED" property. Based on
everything you've said so far, I'd expect you to be using ISA_1_NEEDED
and FEATURE_2_NEEDED instead, and these properties should be in the
OR_AND range.

Why do CMOV, SSE, SSE2, AVX, and AVX512F go in ISA_1_USED, but AVX2
goes in ISA_1_NEEDED?

Why do x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, and XSAVEC go in
FEATURE_2_USED, but XMM and YMM go in FEATURE_2_NEEDED?

How exactly are you expecting these properties to be treated by the loader?

For USED (but optional) features, who is the intended consumer? A
loader can't use them to reject the program on reduced-capability
hardware, since those features are described as optional. Code tagged
with a used-but-optional feature presumably has been written to
dynamically test for the presence of a capability, and use it if it's
present, falling back to a less-preferred mechanism if it's not. Such
a property might be useful for link-time selection of variant
implementations of a routine, or even for load-time selection, but
only if the property remains attached to the specific entry point. As
a binary-wide property, I don't see how it would be of much use. If
the intended consumer is nothing more than a human reader of objdump
output, that's fine, but you're going to an awful lot of work if
that's it.

For NEEDED features, the intent is clearly that the loader can
determine whether the hardware is capable of executing a particular
binary, and rejecting it gracefully if it's not (as opposed to letting
it core dump when it tries to use an absent feature -- or worse!). For
these, it seems silly to discard the whole set of NEEDED features when
even a single input file is missing the property -- after all, even if
that missing input file might need some unique features, it's still
the case that the ones we do know about from other files are still
needed, and it's still desirable to let the loader reject the binary
if it can. This is why I don't really understand your motivation for
the OR_AND rule.

-cary

[H.J. Lu]

Post by Cary Coutant

Post by H.J. Lu
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000030 NT_GNU_PROPERTY_TYPE_0
Properties: x86 feature: IBT, SHSTK
x86 ISA used: CMOV, SSE, SSE2, AVX, AVX512F
x86 feature used: x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC
x86 feature: IBT, SHSTK
is AND/GNU_PROPERTY_X86_FEATURE_1_AND. It is generated
by GCC with -fcf-protection.
x86 ISA used: CMOV, SSE, SSE2, AVX, AVX512F
is OR_AND/GNU_PROPERTY_X86_ISA_1_USED. It is generated by
assembler with -mx86-used-note=yes.
x86 feature used: x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC
is OR_AND/GNU_PROPERTY_X86_FEATURE_2_USED. It is generated
by assembler with -mx86-used-note=yes.
They tell
1. The binary supports IBT and SHSTK.
2. The binary only uses base ISA + CMOV, SSE, SSE2, AVX, AVX512F.
3 The binary only uses x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, XSAVEC.
If someone wants to create a set of binaries for AVX2 and above. He/she
can set AVX2 in OR/GNU_PROPERTY_X86_ISA_1_NEEDED and XMM/YMM
in OR/GNU_PROPERTY_X86_FEATURE_2_NEEDED.
How can I achieve the above with your suggestion?

Before I answer that, let's talk about "NEEDED" vs. "USED".
In the psABI, you have described both ISA_1_USED and FEATURE_2_USED as
(a) You've assigned values for both of these in the OR_AND range,
which you've described earlier in this thread as meaning "It is not OK
if run-time doesn't have the feature the program requires."
(b) Your example from ld-linux-x86-64.so.2 shows ISA_1_USED and
FEATURE_2_USED, but does not use either "NEEDED" property. Based on
everything you've said so far, I'd expect you to be using ISA_1_NEEDED
and FEATURE_2_NEEDED instead, and these properties should be in the
OR_AND range.
Why do CMOV, SSE, SSE2, AVX, and AVX512F go in ISA_1_USED, but AVX2
goes in ISA_1_NEEDED?

When main () executes AVX2 instructions unconditionally, AVX2 is needed.
main () may also call other functions which use CMOV, SSE, SSE2, AVX,
and AVX512F.

Post by Cary Coutant
Why do x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, and XSAVEC go in
FEATURE_2_USED, but XMM and YMM go in FEATURE_2_NEEDED?

When main () executes instructions with XMM and YMM registers unconditionally,
XMM and YMM are needed. main () may also call other functions which use
x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, and XSAVEC.

Post by Cary Coutant
How exactly are you expecting these properties to be treated by the loader?

For example, it can be used to check if a program contains any SSE instructions.
One may want to build a program without SSE. It can be used to verify that.
Unlike ISA_1_USED, only 1 bit in ISA_1_NEEDED is accurate. We can't
use ISA_1_NEEDED to check if a program has any SSE instructions.

Post by Cary Coutant
For USED (but optional) features, who is the intended consumer? A
loader can't use them to reject the program on reduced-capability
hardware, since those features are described as optional. Code tagged
with a used-but-optional feature presumably has been written to
dynamically test for the presence of a capability, and use it if it's
present, falling back to a less-preferred mechanism if it's not. Such
a property might be useful for link-time selection of variant
implementations of a routine, or even for load-time selection, but
only if the property remains attached to the specific entry point. As
a binary-wide property, I don't see how it would be of much use. If
the intended consumer is nothing more than a human reader of objdump
output, that's fine, but you're going to an awful lot of work if
that's it.
For NEEDED features, the intent is clearly that the loader can
determine whether the hardware is capable of executing a particular
binary, and rejecting it gracefully if it's not (as opposed to letting
it core dump when it tries to use an absent feature -- or worse!). For
these, it seems silly to discard the whole set of NEEDED features when
even a single input file is missing the property -- after all, even if
that missing input file might need some unique features, it's still
the case that the ones we do know about from other files are still
needed, and it's still desirable to let the loader reject the binary
if it can. This is why I don't really understand your motivation for
the OR_AND rule.

OR_AND is for accurate 0 bit. Loader may decide to load a program
only if SSE bit is 0.

[Cary Coutant]

Post by H.J. Lu

Post by Cary Coutant
In the psABI, you have described both ISA_1_USED and FEATURE_2_USED as
(a) You've assigned values for both of these in the OR_AND range,
which you've described earlier in this thread as meaning "It is not OK
if run-time doesn't have the feature the program requires."

You haven't responded to this. Either the psABI is wrong or your
explanation earlier in this thread about OR_AND is wrong. Which is it?

In bfd, you treat the USED properties as OR_AND properties, where you
remove the property if one file doesn't provide it, and you treat the
NEEDED properties as OR properties. Given the psABI descriptions of
the USED and NEEDED properties, I think you've got them backwards.

Post by H.J. Lu

Post by Cary Coutant
Why do CMOV, SSE, SSE2, AVX, and AVX512F go in ISA_1_USED, but AVX2
goes in ISA_1_NEEDED?

When main () executes AVX2 instructions unconditionally, AVX2 is needed.
main () may also call other functions which use CMOV, SSE, SSE2, AVX,
and AVX512F.

Post by Cary Coutant
Why do x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, and XSAVEC go in
FEATURE_2_USED, but XMM and YMM go in FEATURE_2_NEEDED?

When main () executes instructions with XMM and YMM registers unconditionally,
XMM and YMM are needed. main () may also call other functions which use
x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, and XSAVEC.

It sounds like you're telling me that you use NEEDED to describe
features that main() uses, and USED to describe what features may be
used by functions that main() calls. That can't be what you mean --
how is that a useful distinction? And how would the linker even
determine that?

Post by H.J. Lu

Post by Cary Coutant
How exactly are you expecting these properties to be treated by the loader?

For example, it can be used to check if a program contains any SSE instructions.
One may want to build a program without SSE. It can be used to verify that.
Unlike ISA_1_USED, only 1 bit in ISA_1_NEEDED is accurate. We can't
use ISA_1_NEEDED to check if a program has any SSE instructions.

Post by Cary Coutant
For USED (but optional) features, who is the intended consumer? A
loader can't use them to reject the program on reduced-capability
hardware, since those features are described as optional. Code tagged
with a used-but-optional feature presumably has been written to
dynamically test for the presence of a capability, and use it if it's
present, falling back to a less-preferred mechanism if it's not. Such
a property might be useful for link-time selection of variant
implementations of a routine, or even for load-time selection, but
only if the property remains attached to the specific entry point. As
a binary-wide property, I don't see how it would be of much use. If
the intended consumer is nothing more than a human reader of objdump
output, that's fine, but you're going to an awful lot of work if
that's it.
For NEEDED features, the intent is clearly that the loader can
determine whether the hardware is capable of executing a particular
binary, and rejecting it gracefully if it's not (as opposed to letting
it core dump when it tries to use an absent feature -- or worse!). For
these, it seems silly to discard the whole set of NEEDED features when
even a single input file is missing the property -- after all, even if
that missing input file might need some unique features, it's still
the case that the ones we do know about from other files are still
needed, and it's still desirable to let the loader reject the binary
if it can. This is why I don't really understand your motivation for
the OR_AND rule.

OR_AND is for accurate 0 bit. Loader may decide to load a program
only if SSE bit is 0.

Please explain what you expect the loader (and other consumers) to do
with the USED and NEEDED bits. This explanation ought to be in the
psABI.

-cary

[H.J. Lu]

Post by Cary Coutant

Post by H.J. Lu

Post by Cary Coutant
In the psABI, you have described both ISA_1_USED and FEATURE_2_USED as
(a) You've assigned values for both of these in the OR_AND range,
which you've described earlier in this thread as meaning "It is not OK
if run-time doesn't have the feature the program requires."

You haven't responded to this. Either the psABI is wrong or your
explanation earlier in this thread about OR_AND is wrong. Which is it?
In bfd, you treat the USED properties as OR_AND properties, where you
remove the property if one file doesn't provide it, and you treat the
NEEDED properties as OR properties. Given the psABI descriptions of
the USED and NEEDED properties, I think you've got them backwards.

There are

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. If the bit is 1, some input relocatables have the
feature. If
the bit is 0 or the property is missing, it is unknown whether any
input relocatables
have the feature.

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 have unknown values. When all bits in the the
output 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.

How do they differ from bfd linker?

Post by Cary Coutant

Post by H.J. Lu

Post by Cary Coutant
Why do CMOV, SSE, SSE2, AVX, and AVX512F go in ISA_1_USED, but AVX2
goes in ISA_1_NEEDED?

When main () executes AVX2 instructions unconditionally, AVX2 is needed.
main () may also call other functions which use CMOV, SSE, SSE2, AVX,
and AVX512F.

Post by Cary Coutant
Why do x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, and XSAVEC go in
FEATURE_2_USED, but XMM and YMM go in FEATURE_2_NEEDED?

When main () executes instructions with XMM and YMM registers unconditionally,
XMM and YMM are needed. main () may also call other functions which use
x86, x87, XMM, YMM, ZMM, FXSR, XSAVE, and XSAVEC.

It sounds like you're telling me that you use NEEDED to describe
features that main() uses, and USED to describe what features may be

An x86 program main () may contain AVX512 instructions, whose usage is
guarded by CPUID. NEEDED describes features that main() uses without
CPUID check. In this case, AVX512 is USED, not NEEDED.

Post by Cary Coutant
used by functions that main() calls. That can't be what you mean --
how is that a useful distinction? And how would the linker even
determine that?

Linker just merges properties according to rules in x86-64 psABI.

Post by Cary Coutant

Post by H.J. Lu

Post by Cary Coutant
How exactly are you expecting these properties to be treated by the loader?

For example, it can be used to check if a program contains any SSE instructions.
One may want to build a program without SSE. It can be used to verify that.
Unlike ISA_1_USED, only 1 bit in ISA_1_NEEDED is accurate. We can't
use ISA_1_NEEDED to check if a program has any SSE instructions.

Post by Cary Coutant
For USED (but optional) features, who is the intended consumer? A
loader can't use them to reject the program on reduced-capability
hardware, since those features are described as optional. Code tagged
with a used-but-optional feature presumably has been written to
dynamically test for the presence of a capability, and use it if it's
present, falling back to a less-preferred mechanism if it's not. Such
a property might be useful for link-time selection of variant
implementations of a routine, or even for load-time selection, but
only if the property remains attached to the specific entry point. As
a binary-wide property, I don't see how it would be of much use. If
the intended consumer is nothing more than a human reader of objdump
output, that's fine, but you're going to an awful lot of work if
that's it.
For NEEDED features, the intent is clearly that the loader can
determine whether the hardware is capable of executing a particular
binary, and rejecting it gracefully if it's not (as opposed to letting
it core dump when it tries to use an absent feature -- or worse!). For
these, it seems silly to discard the whole set of NEEDED features when
even a single input file is missing the property -- after all, even if
that missing input file might need some unique features, it's still
the case that the ones we do know about from other files are still
needed, and it's still desirable to let the loader reject the binary
if it can. This is why I don't really understand your motivation for
the OR_AND rule.

OR_AND is for accurate 0 bit. Loader may decide to load a program
only if SSE bit is 0.

Please explain what you expect the loader (and other consumers) to do
with the USED and NEEDED bits. This explanation ought to be in the
psABI.

How about this?

GNU_PROPERTY_X86_FEATURE_2_USED The x86 processor features indicated
by the corresponding bits are used in program. Their support in the hardware is
optional. Its absence in an x86 ELF binary implies that any x86
processor features
may be used. GNU_PROPERTY_X86_FEATURE_2_USED can be used to check
for features used in the program.

GNU_PROPERTY_X86_FEATURE_2_NEEDED The x86 processor features
indicated by the corresponding bits are used in program and they must be
supported by the hardware. Loader may refuse to load the program whose
GNU_PROPERTY_X86_FEATURE_2_NEEDED features aren’t supported by the
hardware.

GNU_PROPERTY_X86_ISA_1_NEEDED The x86 instruction sets indicated by the
corresponding bits are used in program and they must be supported by
the hardware.
Loader may refuse to load the program whose GNU_PROPERTY_X86_ISA_1_NEEDED
ISAs aren’t supported by the hardware.

GNU_PROPERTY_X86_ISA_1_USED The x86 instruction sets indicated by the
corresponding bits are used in program. Their support in the hardware
is optional.
GNU_PROPERTY_X86_ISA_1_USED can be used to check for ISAs used in the
program.

[Cary Coutant]

Post by H.J. Lu
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. If the bit is 1, some input relocatables have the
feature. If
the bit is 0 or the property is missing, it is unknown whether any
input relocatables
have the feature.
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 have unknown values. When all bits in the the
output 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.
How do they differ from bfd linker?

I didn't say they did. Indeed, it seems that bfd linker implements
these ranges as documented. But see below.

Post by H.J. Lu
An x86 program main () may contain AVX512 instructions, whose usage is
guarded by CPUID. NEEDED describes features that main() uses without
CPUID check. In this case, AVX512 is USED, not NEEDED.

Fine. That's what I at first presumed, until you said that bit about
"NEEDED is for main() and USED is for functions that main() may call".
That was very misleading.

Post by H.J. Lu
How about this?
GNU_PROPERTY_X86_FEATURE_2_USED The x86 processor features indicated
by the corresponding bits are used in program. Their support in the hardware is
optional. Its absence in an x86 ELF binary implies that any x86
processor features
may be used. GNU_PROPERTY_X86_FEATURE_2_USED can be used to check
for features used in the program.
GNU_PROPERTY_X86_FEATURE_2_NEEDED The x86 processor features
indicated by the corresponding bits are used in program and they must be
supported by the hardware. Loader may refuse to load the program whose
GNU_PROPERTY_X86_FEATURE_2_NEEDED features aren’t supported by the
hardware.
GNU_PROPERTY_X86_ISA_1_NEEDED The x86 instruction sets indicated by the
corresponding bits are used in program and they must be supported by
the hardware.
Loader may refuse to load the program whose GNU_PROPERTY_X86_ISA_1_NEEDED
ISAs aren’t supported by the hardware.
GNU_PROPERTY_X86_ISA_1_USED The x86 instruction sets indicated by the
corresponding bits are used in program. Their support in the hardware
is optional.
GNU_PROPERTY_X86_ISA_1_USED can be used to check for ISAs used in the
program.

This is also fine. But it's not what you've implemented!

You've implemented these with the USED properties in the OR_AND range,
and the NEEDED properties in the OR range:

Table 5.3: Program Property Types
Name Value
GNU_PROPERTY_X86_FEATURE_1_AND GNU_PROPERTY_X86_UINT32_AND_LO + 0
GNU_PROPERTY_X86_FEATURE_2_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 1
GNU_PROPERTY_X86_FEATURE_2_NEEDED GNU_PROPERTY_X86_UINT32_OR_LO + 1
GNU_PROPERTY_X86_ISA_1_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 0
GNU_PROPERTY_X86_ISA_1_NEEDED GNU_PROPERTY_X86_UINT32_OR_LO + 0

The way you've defined the values, ISA_1_USED uses the OR_AND rule,
which implements the behavior you want for ISA_1_NEEDED. ISA_1_NEEDED
uses the OR rule, which implements the behavior you want for
ISA_1_USED. Likewise for FEATURE_2_USED and FEATURE_2_NEEDED.

-cary

[H.J. Lu]

Post by Cary Coutant

Post by H.J. Lu
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. If the bit is 1, some input relocatables have the
feature. If
the bit is 0 or the property is missing, it is unknown whether any
input relocatables
have the feature.
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 have unknown values. When all bits in the the
output 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.
How do they differ from bfd linker?

I didn't say they did. Indeed, it seems that bfd linker implements
these ranges as documented. But see below.

Post by H.J. Lu
An x86 program main () may contain AVX512 instructions, whose usage is
guarded by CPUID. NEEDED describes features that main() uses without
CPUID check. In this case, AVX512 is USED, not NEEDED.

Fine. That's what I at first presumed, until you said that bit about
"NEEDED is for main() and USED is for functions that main() may call".
That was very misleading.

Post by H.J. Lu
How about this?
GNU_PROPERTY_X86_FEATURE_2_USED The x86 processor features indicated
by the corresponding bits are used in program. Their support in the hardware is
optional. Its absence in an x86 ELF binary implies that any x86
processor features
may be used. GNU_PROPERTY_X86_FEATURE_2_USED can be used to check
for features used in the program.
GNU_PROPERTY_X86_FEATURE_2_NEEDED The x86 processor features
indicated by the corresponding bits are used in program and they must be
supported by the hardware. Loader may refuse to load the program whose
GNU_PROPERTY_X86_FEATURE_2_NEEDED features aren’t supported by the
hardware.
GNU_PROPERTY_X86_ISA_1_NEEDED The x86 instruction sets indicated by the
corresponding bits are used in program and they must be supported by
the hardware.
Loader may refuse to load the program whose GNU_PROPERTY_X86_ISA_1_NEEDED
ISAs aren’t supported by the hardware.
GNU_PROPERTY_X86_ISA_1_USED The x86 instruction sets indicated by the
corresponding bits are used in program. Their support in the hardware
is optional.
GNU_PROPERTY_X86_ISA_1_USED can be used to check for ISAs used in the
program.

This is also fine. But it's not what you've implemented!
You've implemented these with the USED properties in the OR_AND range,
Table 5.3: Program Property Types
Name Value
GNU_PROPERTY_X86_FEATURE_1_AND GNU_PROPERTY_X86_UINT32_AND_LO + 0
GNU_PROPERTY_X86_FEATURE_2_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 1
GNU_PROPERTY_X86_FEATURE_2_NEEDED GNU_PROPERTY_X86_UINT32_OR_LO + 1
GNU_PROPERTY_X86_ISA_1_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 0
GNU_PROPERTY_X86_ISA_1_NEEDED GNU_PROPERTY_X86_UINT32_OR_LO + 0
The way you've defined the values, ISA_1_USED uses the OR_AND rule,
which implements the behavior you want for ISA_1_NEEDED. ISA_1_NEEDED
uses the OR rule, which implements the behavior you want for
ISA_1_USED. Likewise for FEATURE_2_USED and FEATURE_2_NEEDED.

I committed a typo fix. Now it reads

GNU_PROPERTY_X86_FEATURE_2_NEEDED The x86 processor features in-
dicated by the corresponding bits are needed in program and they must be
supported by the hardware. Loader may refuse to load the program whose
GNU_PROPERTY_X86_FEATURE_2_NEEDED features aren’t supported by the
hardware.
GNU_PROPERTY_X86_ISA_1_NEEDED The x86 instruction sets indicated
by the corresponding bits are needed in program and they must be sup-
ported by the hardware.
Loader may refuse to load the program whose
GNU_PROPERTY_X86_ISA_1_NEEDED ISAs aren’t supported by the hardware.

[Cary Coutant]

Post by H.J. Lu

Post by Cary Coutant
The way you've defined the values, ISA_1_USED uses the OR_AND rule,
which implements the behavior you want for ISA_1_NEEDED. ISA_1_NEEDED
uses the OR rule, which implements the behavior you want for
ISA_1_USED. Likewise for FEATURE_2_USED and FEATURE_2_NEEDED.

I committed a typo fix. Now it reads
GNU_PROPERTY_X86_FEATURE_2_NEEDED The x86 processor features in-
dicated by the corresponding bits are needed in program and they must be
supported by the hardware. Loader may refuse to load the program whose
GNU_PROPERTY_X86_FEATURE_2_NEEDED features aren’t supported by the
hardware.
GNU_PROPERTY_X86_ISA_1_NEEDED The x86 instruction sets indicated
by the corresponding bits are needed in program and they must be sup-
ported by the hardware.
Loader may refuse to load the program whose
GNU_PROPERTY_X86_ISA_1_NEEDED ISAs aren’t supported by the hardware.

That doesn't fix a thing. Here's the fix you need:

Table 5.3: Program Property Types
Name Value
GNU_PROPERTY_X86_FEATURE_1_AND GNU_PROPERTY_X86_UINT32_AND_LO + 0
- GNU_PROPERTY_X86_FEATURE_2_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 1
+ GNU_PROPERTY_X86_FEATURE_2_USED GNU_PROPERTY_X86_UINT32_OR_LO + 1
- GNU_PROPERTY_X86_FEATURE_2_NEEDED GNU_PROPERTY_X86_UINT32_OR_LO + 1
+ GNU_PROPERTY_X86_FEATURE_2_NEEDED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 1
- GNU_PROPERTY_X86_ISA_1_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 0
+ GNU_PROPERTY_X86_ISA_1_USED GNU_PROPERTY_X86_UINT32_OR_LO + 0
- GNU_PROPERTY_X86_ISA_1_NEEDED GNU_PROPERTY_X86_UINT32_OR_LO + 0
+ GNU_PROPERTY_X86_ISA_1_NEEDED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 0

And this:

--- a/bfd/elfxx-x86.c
+++ b/bfd/elfxx-x86.c
@@ -2408,7 +2408,7 @@ _bfd_x86_elf_merge_gnu_properties (struct
bfd_link_info *info,
bfd_boolean updated = FALSE;
unsigned int pr_type = aprop != NULL ? aprop->pr_type : bprop->pr_type;

- if (pr_type == GNU_PROPERTY_X86_COMPAT_ISA_1_USED
+ if (pr_type == GNU_PROPERTY_X86_COMPAT_ISA_1_NEEDED
|| (pr_type >= GNU_PROPERTY_X86_UINT32_OR_AND_LO
&& pr_type <= GNU_PROPERTY_X86_UINT32_OR_AND_HI))
{
@@ -2426,7 +2426,7 @@ _bfd_x86_elf_merge_gnu_properties (struct
bfd_link_info *info,
}
goto or_property;
}
- else if (pr_type == GNU_PROPERTY_X86_COMPAT_ISA_1_NEEDED
+ else if (pr_type == GNU_PROPERTY_X86_COMPAT_ISA_1_USED
|| (pr_type >= GNU_PROPERTY_X86_UINT32_OR_LO
&& pr_type <= GNU_PROPERTY_X86_UINT32_OR_HI))
{

-cary

[H.J. Lu]

Post by Cary Coutant

Post by H.J. Lu

Post by Cary Coutant
The way you've defined the values, ISA_1_USED uses the OR_AND rule,
which implements the behavior you want for ISA_1_NEEDED. ISA_1_NEEDED
uses the OR rule, which implements the behavior you want for
ISA_1_USED. Likewise for FEATURE_2_USED and FEATURE_2_NEEDED.

I committed a typo fix. Now it reads
GNU_PROPERTY_X86_FEATURE_2_NEEDED The x86 processor features in-
dicated by the corresponding bits are needed in program and they must be
supported by the hardware. Loader may refuse to load the program whose
GNU_PROPERTY_X86_FEATURE_2_NEEDED features aren’t supported by the
hardware.
GNU_PROPERTY_X86_ISA_1_NEEDED The x86 instruction sets indicated
by the corresponding bits are needed in program and they must be sup-
ported by the hardware.
Loader may refuse to load the program whose
GNU_PROPERTY_X86_ISA_1_NEEDED ISAs aren’t supported by the hardware.

Table 5.3: Program Property Types
Name Value
GNU_PROPERTY_X86_FEATURE_1_AND GNU_PROPERTY_X86_UINT32_AND_LO + 0
- GNU_PROPERTY_X86_FEATURE_2_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 1
+ GNU_PROPERTY_X86_FEATURE_2_USED GNU_PROPERTY_X86_UINT32_OR_LO + 1
- GNU_PROPERTY_X86_FEATURE_2_NEEDED GNU_PROPERTY_X86_UINT32_OR_LO + 1
+ GNU_PROPERTY_X86_FEATURE_2_NEEDED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 1
- GNU_PROPERTY_X86_ISA_1_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 0
+ GNU_PROPERTY_X86_ISA_1_USED GNU_PROPERTY_X86_UINT32_OR_LO + 0
- GNU_PROPERTY_X86_ISA_1_NEEDED GNU_PROPERTY_X86_UINT32_OR_LO + 0
+ GNU_PROPERTY_X86_ISA_1_NEEDED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 0

That is not right. It should be

1. USED follows OR_AND.
2. NEEDED follows OR,

Can you point me where x86-64 psABI says otherwise?

Post by Cary Coutant
--- a/bfd/elfxx-x86.c
+++ b/bfd/elfxx-x86.c
@@ -2408,7 +2408,7 @@ _bfd_x86_elf_merge_gnu_properties (struct
bfd_link_info *info,
bfd_boolean updated = FALSE;
unsigned int pr_type = aprop != NULL ? aprop->pr_type : bprop->pr_type;
- if (pr_type == GNU_PROPERTY_X86_COMPAT_ISA_1_USED
+ if (pr_type == GNU_PROPERTY_X86_COMPAT_ISA_1_NEEDED
|| (pr_type >= GNU_PROPERTY_X86_UINT32_OR_AND_LO
&& pr_type <= GNU_PROPERTY_X86_UINT32_OR_AND_HI))
{
@@ -2426,7 +2426,7 @@ _bfd_x86_elf_merge_gnu_properties (struct
bfd_link_info *info,
}
goto or_property;
}
- else if (pr_type == GNU_PROPERTY_X86_COMPAT_ISA_1_NEEDED
+ else if (pr_type == GNU_PROPERTY_X86_COMPAT_ISA_1_USED
|| (pr_type >= GNU_PROPERTY_X86_UINT32_OR_LO
&& pr_type <= GNU_PROPERTY_X86_UINT32_OR_HI))
{
-cary

[Cary Coutant]

Post by H.J. Lu
That is not right. It should be
1. USED follows OR_AND.
2. NEEDED follows OR,
Can you point me where x86-64 psABI says otherwise?

I have done so several times:

https://sourceware.org/ml/binutils/2018-11/msg00263.html
https://sourceware.org/ml/binutils/2018-12/msg00008.html
https://sourceware.org/ml/binutils/2018-12/msg00045.html
https://sourceware.org/ml/binutils/2018-12/msg00048.html

-cary

[H.J. Lu]

Post by Cary Coutant

Post by H.J. Lu
That is not right. It should be
1. USED follows OR_AND.
2. NEEDED follows OR,
Can you point me where x86-64 psABI says otherwise?

https://sourceware.org/ml/binutils/2018-11/msg00263.html
https://sourceware.org/ml/binutils/2018-12/msg00008.html
https://sourceware.org/ml/binutils/2018-12/msg00045.html
https://sourceware.org/ml/binutils/2018-12/msg00048.html

Let's take GNU_PROPERTY_X86_FEATURE_2_USED. Here are
what x86-64 psABI says:

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 have unknown values. When all bits in the the
output 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.

GNU_PROPERTY_X86_FEATURE_2_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 1

GNU_PROPERTY_X86_FEATURE_2_USED The x86 processor features indicated
by the corresponding bits are used in program. Their support in the hardware is
optional. Its absence in an x86 ELF binary implies that any x86
processor features
may be used. GNU_PROPERTY_X86_FEATURE_2_USED can be used to check
for features used in the program

[***@gnu-cfl-1 tmp]$ cat foo.s
.text
movaps %xmm0, %xmm0
[***@gnu-cfl-1 tmp]$ as -mx86-used-note=no foo.s -o foo1.o
[***@gnu-cfl-1 tmp]$ as -mx86-used-note=yes foo.s -o foo2.o
[***@gnu-cfl-1 tmp]$ as -mx86-used-note=yes foo.s -o foo3.o
[***@gnu-cfl-1 tmp]$ readelf -n foo1.o
[***@gnu-cfl-1 tmp]$ readelf -n foo2.o

Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA used: SSE
x86 feature used: x86, XMM
[***@gnu-cfl-1 tmp]$ readelf -n foo3.o

Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA used: SSE
x86 feature used: x86, XMM
[***@gnu-cfl-1 tmp]$ ld.bfd foo1.o foo2.o
ld.bfd: warning: cannot find entry symbol _start; defaulting to 0000000000401000
[***@gnu-cfl-1 tmp]$ readelf -n a.out
[***@gnu-cfl-1 tmp]$ ld.bfd foo3.o foo2.o
ld.bfd: warning: cannot find entry symbol _start; defaulting to 0000000000401000
[***@gnu-cfl-1 tmp]$ readelf -n a.out

Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA used: SSE
x86 feature used: x86, XMM
[***@gnu-cfl-1 tmp]$

Can you tell me what the issues are?

[Cary Coutant]

Post by H.J. Lu
Let's take GNU_PROPERTY_X86_FEATURE_2_USED. Here are

OK. Pay particular attention to the parts I've highlighted...

Post by H.J. Lu
GNU_PROPERTY_X86_FEATURE_2_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 1
GNU_PROPERTY_X86_FEATURE_2_USED The x86 processor features
indicated by the corresponding bits are used in program.
*** THEIR SUPPORT IN THE HARDWARE IS OPTIONAL. ***
Its absence in an x86 ELF binary implies that any x86 processor
features may be used. GNU_PROPERTY_X86_FEATURE_2_USED can be used
to check for features used in the program.
1. AND: It is OK if run-time doesn't have the feature the
program supports, like CET.
2. OR_AND: *** IT IS NOT OK IF RUN-TIME DOESN'T HAVE THE FEATURE
THE PROGRAM REQUIRES, LIKE NEEDED AVX512 ***
1 bit: Yes. 0 bit: Unknown.
AND and OR_AND are useful for loaders and must be originated by
compiler or programmer. *** OR MAY BE GENERATED AUTOMATICALLY
BY ASSEMBLER. ***

You say USED bits correspond to features that are optional, but you
say OR_AND is for features that are required. You say OR may be
generated automatically by the assembler, but you have the assembler
generating the USED bits automatically. You say OR_AND must be
originated by the compiler or programmer -- those are clearly for the
NEEDED features, since the assembler cannot automatically determine
whether the use of an instruction is guarded by a CPUID check.

-cary

[1] https://sourceware.org/ml/binutils/2018-11/msg00238.html

[H.J. Lu]

Post by Cary Coutant

Post by H.J. Lu
Let's take GNU_PROPERTY_X86_FEATURE_2_USED. Here are

OK. Pay particular attention to the parts I've highlighted...

Post by H.J. Lu
GNU_PROPERTY_X86_FEATURE_2_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 1
GNU_PROPERTY_X86_FEATURE_2_USED The x86 processor features
indicated by the corresponding bits are used in program.
*** THEIR SUPPORT IN THE HARDWARE IS OPTIONAL. ***
Its absence in an x86 ELF binary implies that any x86 processor
features may be used. GNU_PROPERTY_X86_FEATURE_2_USED can be used
to check for features used in the program.
1. AND: It is OK if run-time doesn't have the feature the
program supports, like CET.
2. OR_AND: *** IT IS NOT OK IF RUN-TIME DOESN'T HAVE THE FEATURE
THE PROGRAM REQUIRES, LIKE NEEDED AVX512 ***
1 bit: Yes. 0 bit: Unknown.
AND and OR_AND are useful for loaders and must be originated by
compiler or programmer. *** OR MAY BE GENERATED AUTOMATICALLY
BY ASSEMBLER. ***

You say USED bits correspond to features that are optional, but you
say OR_AND is for features that are required. You say OR may be
generated automatically by the assembler, but you have the assembler
generating the USED bits automatically. You say OR_AND must be
originated by the compiler or programmer -- those are clearly for the
NEEDED features, since the assembler cannot automatically determine
whether the use of an instruction is guarded by a CPUID check.
-cary
[1] https://sourceware.org/ml/binutils/2018-11/msg00238.html

I misspoke in [1]. x86-64 psABI describes the correct behavior.

[Cary Coutant]

Post by H.J. Lu
I misspoke in [1]. x86-64 psABI describes the correct behavior.

I see.

But I don't see the point of removing the property if it's missing in
any input. I didn't see much point in doing it for NEEDED bits either,
but at least it made slightly more sense to me than doing it for the
USED bits.

So that brings me back to a basic question: What is the purpose of the
USED bits?

Who or what is going to look at them, and what decision are they going
to make based on them?

The loader can't use them -- it only cares about NEEDED features
(which, as far as I can tell, are still not implemented). If the
loader can't use them, why are they in the .note.gnu.properties
section rather than the non-allocated GNU build attributes section?
(See [2].)

They can tell you if SSE instructions are used, for example, but they
can't tell you how many places they're used, what functions use them,
or even whether they're guarded by runtime CPUID tests. They might
even be used only in some unreachable function (which might even have
been garbage-collected!). You could easily add an option to objdump
that would scan the binary and give you much more useful information.

-cary

[2] https://fedoraproject.org/wiki/Toolchain/Watermark#Markup_for_ELF_objects


-cary

[Jim Dehnert]

Something's been bothering me about much of this discussion, which is
probably related to Cary's question about intended usage. We had some
features analogous to these, for example concerning floating point
behavior, in the SGI compilers and tools 20+ years ago. One of the things
we realized in the process was that there are at least two different
classes of usage with different desired properties.

The first class involves what this discussion is focused on -- the ability
to catch invalid mixtures of assumptions, e.g., code that assumes or
requires something (like your X86 features) vs. other code or hardware that
doesn't satisfy those requirements. When one catches such a mismatch (in
the linker or loader, say), one could reject the program, or it might be
preferable to let it pass and just use the information for better error
messages if a failure occurs at runtime. The latter decision might make
sense if an actual failure is unlikely, but the decision might vary for
different features, or different tools, or different vendors.

For such usage, it is not necessarily critical that the property
information be available for every component object. For example, it may
be known that old objects created before the property became available
didn't ever require it. It may also be desirable to just accept objects
from toolchains that don't (yet) support the property bits, and accept that
they might fail more dramatically.

The second class involves things like cross-object optimization decisions,
where some global attribute must apply to make the optimization valid. In
this case, missing information might produce an incorrect optimization. An
example might be a linker decision to include software FP support for a
simple processor depending on whether any object uses FP.

The point of bringing up this distinction is that the same property
information might be used by different tools or toolchains, or in different
contexts, in different ways in terms of whether a property is required or
not, and in terms of whether accurate information is required from all
component objects. It's not a good idea to make assumptions when defining
the property bit treatment about which case applies -- you should just
carefully define what the bit means, how it's combined when linking objects
(AND vs. OR), and, importantly, how a downstream consumer knows whether or
not the information is complete. In particular, a decision to discard data
if it's missing from some objects, or if the operation applied yields a
particular result, can make it impossible for a downstream consumer to tell
the difference between missing information and combinations yielding 0, and
it removes the ability of a consumer to do something intelligent for the
first case.

The above are general observations. There's a more subtle issue in this
particular proposal that's related (as I understand it). Because you're
packing property bits into larger units, and will presumably be adding
additional properties in the future, you'll want to be able to tell which
bits are valid in a particular object (e.g., was it created before or after
the new property was added?). Otherwise, bits might be zero either because
the property isn't true, or because it wasn't supported by the tool
that created the object. You can't really deal with this using version
information, because there's no good way to combine versions without
discarding information. I'd suggest including a "complete" bit for each
property bit, meaning that all components of the object provided valid
values for the property. Non-complete property bits could still contain
useful data, but a consumer could not assume it was a valid combination of
all the component objects. (This implies that the complete bits are all
AND bits - the output value should be an AND of all the input values when
combining objects.) Note that the separate complete bits removes the need
for the OR_AND construct, which was trying to combine two separate concepts
in a single bit.

Post by H.J. Lu
Let's take GNU_PROPERTY_X86_FEATURE_2_USED. Here are
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 have unknown values. When all bits in the the
output 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.

Based on the above, this is not a good idea. The property should be
present in output if it was present in any input, and its value should
probably reflect the combination of those inputs. A complete bit can
provide this last bit of information, which can have utility independent of
the (possibly partial) combined property bits. Besides, you can't remove a
subset of the property bits in a storage unit anyway, if the input objects
were generated by tools supporting different numbers of them.

Post by H.J. Lu
GNU_PROPERTY_X86_FEATURE_2_USED GNU_PROPERTY_X86_UINT32_OR_AND_LO + 1
GNU_PROPERTY_X86_FEATURE_2_USED The x86 processor features indicated
by the corresponding bits are used in program. Their support in the hardware is
optional. Its absence in an x86 ELF binary implies that any x86
processor features
may be used. GNU_PROPERTY_X86_FEATURE_2_USED can be used to check
for features used in the program
.text
movaps %xmm0, %xmm0
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA used: SSE
x86 feature used: x86, XMM
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA used: SSE
x86 feature used: x86, XMM
ld.bfd: warning: cannot find entry symbol _start; defaulting to 0000000000401000
ld.bfd: warning: cannot find entry symbol _start; defaulting to 0000000000401000
Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA used: SSE
x86 feature used: x86, XMM
Can you tell me what the issues are?
--
H.J.
--
You received this message because you are subscribed to the Google Groups
"X86-64 System V Application Binary Interface" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[H.J. Lu]

Something's been bothering me about much of this discussion, which is probably related to Cary's question about intended usage. We had some features analogous to these, for example concerning floating point behavior, in the SGI compilers and tools 20+ years ago. One of the things we realized in the process was that there are at least two different classes of usage with different desired properties.
The first class involves what this discussion is focused on -- the ability to catch invalid mixtures of assumptions, e.g., code that assumes or requires something (like your X86 features) vs. other code or hardware that doesn't satisfy those requirements. When one catches such a mismatch (in the linker or loader, say), one could reject the program, or it might be preferable to let it pass and just use the information for better error messages if a failure occurs at runtime. The latter decision might make sense if an actual failure is unlikely, but the decision might vary for different features, or different tools, or different vendors.
For such usage, it is not necessarily critical that the property information be available for every component object. For example, it may be known that old objects created before the property became available didn't ever require it. It may also be desirable to just accept objects from toolchains that don't (yet) support the property bits, and accept that they might fail more dramatically.
The second class involves things like cross-object optimization decisions, where some global attribute must apply to make the optimization valid. In this case, missing information might produce an incorrect optimization. An example might be a linker decision to include software FP support for a simple processor depending on whether any object uses FP.
The point of bringing up this distinction is that the same property information might be used by different tools or toolchains, or in different contexts, in different ways in terms of whether a property is required or not, and in terms of whether accurate information is required from all component objects. It's not a good idea to make assumptions when defining the property bit treatment about which case applies -- you should just carefully define what the bit means, how it's combined when linking objects (AND vs. OR), and, importantly, how a downstream consumer knows whether or not the information is complete. In particular, a decision to discard data if it's missing from some objects, or if the operation applied yields a particular result, can make it impossible for a downstream consumer to tell the difference between missing information and combinations yielding 0, and it removes the ability of a consumer to do something intelligent for the first case.
The above are general observations. There's a more subtle issue in this particular proposal that's related (as I understand it). Because you're packing property bits into larger units, and will presumably be adding additional properties in the future, you'll want to be able to tell which bits are valid in a particular object (e.g., was it created before or after the new property was added?). Otherwise, bits might be zero either because the property isn't true, or because it wasn't supported by the tool that created the object. You can't really deal with this using version information, because there's no good way to combine versions without discarding information. I'd suggest including a "complete" bit for each property bit, meaning that all components of the object provided valid values for the property. Non-complete property bits could still contain useful data, but a consumer could not assume it was a valid combination of all the component objects. (This implies that the complete bits are all AND bits - the output value should be an AND of all the input values when combining objects.) Note that the separate complete bits removes the need for the OR_AND construct, which was trying to combine two separate concepts in a single bit.

Thanks Jim. Your description pretty much captures my intention.
OR_AND provides a way to
mark an object with complete info. If the bit is 1, the feature
exists. If the bit is 0, the feature does
not exist. A "complete" bit is an interesting idea. How should it
be mapped to NEEDED and USED
properties? I have

[***@gnu-cfl-2 ld-plugin]$ readelf -n /bin/ld | head

Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000020 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA used: CMOV, SSE, SSE2
x86 feature used: x86, XMM

So /bin/ld only uses x86 and XMM with CMOV, SSE, SSE2 and nothing else.
This info is generated by

as:

-mx86-used-note=[no|yes] (default: yes)
generate x86 used ISA and feature properties

and linker automatically. How can I achieve the same with a "complete" bit?

[Cary Coutant]

Post by Jim Dehnert
The above are general observations. There's a more subtle issue
in this particular proposal that's related (as I understand it).
Because you're packing property bits into larger units, and will
presumably be adding additional properties in the future, you'll
want to be able to tell which bits are valid in a particular
object (e.g., was it created before or after the new property was
added?). Otherwise, bits might be zero either because the
property isn't true, or because it wasn't supported by the tool
that created the object. You can't really deal with this using
version information, because there's no good way to combine
versions without discarding information. I'd suggest including a
"complete" bit for each property bit, meaning that all components
of the object provided valid values for the property.
Non-complete property bits could still contain useful data, but a
consumer could not assume it was a valid combination of all the
component objects. (This implies that the complete bits are all
AND bits - the output value should be an AND of all the input
values when combining objects.) Note that the separate complete
bits removes the need for the OR_AND construct, which was trying
to combine two separate concepts in a single bit.
Thanks Jim. Your description pretty much captures my intention.
OR_AND provides a way to
mark an object with complete info. If the bit is 1, the feature
exists. If the bit is 0, the feature does
not exist. A "complete" bit is an interesting idea. How should it
be mapped to NEEDED and USED
properties? I have

This brings us back to what I was talking about in [3], where I
suggested using FEATURE_X_KNOWN and FEATURE_X_NEEDED properties. What
Jim calls "complete" bits are what I called "known" bits.

Basically, every producer that generates a set of NEEDED properties
would also generate a corresponding set of KNOWN properties, which
consist of all ones for the properties that the producer knows about
at the time. These would be ANDed together, while the NEEDED
properties would be ORed together. In the final executable, you'd have
a set of KNOWN bits that indicate whether the value for that property
is known in all inputs, and a set of NEEDED bits that indicate whether
the property was needed by at least one input. If a NEEDED bit is 1,
you know that feature is needed. If a NEEDED bit is 0, and the KNOWN
bit is 1, you know that feature is not needed. Otherwise (KNOWN bit is
0 and NEEDED bit is 0), it is unknown.

You could use known/complete bits for ISA_1_USED, ISA_1_NEEDED,
FEATURE_2_USED, and FEATURE_2_NEEDED. If you always generate both USED
and NEEDED bits, you might be able to get away with one ISA_1_KNOWN
for both ISA_1_USED and ISA_1_NEEDED, and one FEATURE_2_KNOWN for both
FEATURE_2_USED and FEATURE_2_NEEDED. But since you are currently
generating only USED bits, and NEEDED bits will presumably come later,
you'll probably want a separate set of KNOWN bits for each property.

(I'm still questioning the usefulness of the USED bits, though.)

-cary

[3] https://sourceware.org/ml/binutils/2018-11/msg00263.html