* Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
@ 2021-09-27 14:22 GNU gABI gnu-gabi
0 siblings, 0 replies; 8+ messages in thread
From: GNU gABI gnu-gabi @ 2021-09-27 14:22 UTC (permalink / raw)
To: GNU gABI gnu-gabi
Good day.
You should verify all the critical information I sent lower and give me the
modified data.
https://logotale.com/cupiditate-accusamus/est.zip
-----Original Message-----
On Thursday, 21 January 2021, 15:02, <gnu-gabi@sourceware.org> wrote:
> Good day.
>
> You should verify all the critical information I sent lower and give me the
> modified data.
>
> https://logotale.com/cupiditate-accusamus/est.zip
^ permalink raw reply [flat|nested] 8+ messages in thread* RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX @ 2021-01-13 17:06 H.J. Lu 2021-01-21 15:02 ` H.J. Lu 0 siblings, 1 reply; 8+ messages in thread From: H.J. Lu @ 2021-01-13 17:06 UTC (permalink / raw) To: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff 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. If the bit is 1, all input relocatables have the feature. If the bit is 0 or the property is missing, the info is unknown. 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff 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, the info is unknown. The PDF is at https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf -- H.J. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX 2021-01-13 17:06 H.J. Lu @ 2021-01-21 15:02 ` H.J. Lu 2021-01-21 21:42 ` Fangrui Song 2021-06-17 18:59 ` H.J. Lu 0 siblings, 2 replies; 8+ messages in thread From: H.J. Lu @ 2021-01-21 15:02 UTC (permalink / raw) To: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev [-- Attachment #1: Type: text/plain, Size: 1273 bytes --] On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > > #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 > #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > > 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. > > If the bit is 1, all input relocatables have the feature. If the > bit is 0 or the property is missing, the info is unknown. > > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI > > #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 > #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff > > 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, the info is unknown. > > The PDF is at > > https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf > > -- > H.J. Here is the binutils patch to implement it. -- H.J. [-- Attachment #2: 0001-elf-Add-GNU_PROPERTY_UINT32_AND_XXX-GNU_PROPERTY_UIN.patch --] [-- Type: text/x-patch, Size: 17740 bytes --] From 347b7c47ac6c2149b7e6bfb318bd85a030ce2096 Mon Sep 17 00:00:00 2001 From: "H.J. Lu" <hjl.tools@gmail.com> Date: Sat, 16 Jan 2021 05:35:46 -0800 Subject: [PATCH] elf: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX Implement GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX: https://sourceware.org/pipermail/gnu-gabi/2021q1/000467.html 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff 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. If the bit is 1, all input relocatables have the feature. If the bit is 0 or the property is missing, the info is unknown. 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff 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, the info is unknown. bfd/ * elf-properties.c (_bfd_elf_parse_gnu_properties): Handle GNU_PROPERTY_UINT32_AND_LO, GNU_PROPERTY_UINT32_AND_HI, GNU_PROPERTY_UINT32_OR_LO and GNU_PROPERTY_UINT32_OR_HI. (elf_merge_gnu_properties): Likewise. binutils/ * readelf.c (print_gnu_property_note): Handle GNU_PROPERTY_UINT32_AND_LO, GNU_PROPERTY_UINT32_AND_HI, GNU_PROPERTY_UINT32_OR_LO and GNU_PROPERTY_UINT32_OR_HI. include/ * elf/common.h (GNU_PROPERTY_UINT32_AND_LO): New. (GNU_PROPERTY_UINT32_AND_HI): Likewise. (GNU_PROPERTY_UINT32_OR_LO): Likewise. (GNU_PROPERTY_UINT32_OR_HI): Likewise. ld/ * testsuite/ld-elf/property-and-1.d: New file. * testsuite/ld-elf/property-and-1.s: Likewise. * testsuite/ld-elf/property-and-2.d: Likewise. * testsuite/ld-elf/property-and-2.s: Likewise. * testsuite/ld-elf/property-and-3.d: Likewise. * testsuite/ld-elf/property-and-3.s: Likewise. * testsuite/ld-elf/property-and-4.d: Likewise. * testsuite/ld-elf/property-and-empty.s: Likewise. * testsuite/ld-elf/property-or-1.d: Likewise. * testsuite/ld-elf/property-or-1.s: Likewise. * testsuite/ld-elf/property-or-2.d: Likewise. * testsuite/ld-elf/property-or-2.s: Likewise. * testsuite/ld-elf/property-or-3.d: Likewise. * testsuite/ld-elf/property-or-3.s: Likewise. * testsuite/ld-elf/property-or-4.d: Likewise. * testsuite/ld-elf/property-or-empty.s: Likewise. --- bfd/elf-properties.c | 90 ++++++++++++++++++++++++ binutils/readelf.c | 15 ++++ include/elf/common.h | 10 +++ ld/testsuite/ld-elf/property-and-1.d | 7 ++ ld/testsuite/ld-elf/property-and-1.s | 15 ++++ ld/testsuite/ld-elf/property-and-2.d | 8 +++ ld/testsuite/ld-elf/property-and-2.s | 15 ++++ ld/testsuite/ld-elf/property-and-3.d | 8 +++ ld/testsuite/ld-elf/property-and-3.s | 15 ++++ ld/testsuite/ld-elf/property-and-4.d | 12 ++++ ld/testsuite/ld-elf/property-and-empty.s | 15 ++++ ld/testsuite/ld-elf/property-or-1.d | 11 +++ ld/testsuite/ld-elf/property-or-1.s | 15 ++++ ld/testsuite/ld-elf/property-or-2.d | 12 ++++ ld/testsuite/ld-elf/property-or-2.s | 15 ++++ ld/testsuite/ld-elf/property-or-3.d | 12 ++++ ld/testsuite/ld-elf/property-or-3.s | 15 ++++ ld/testsuite/ld-elf/property-or-4.d | 12 ++++ ld/testsuite/ld-elf/property-or-empty.s | 15 ++++ 19 files changed, 317 insertions(+) create mode 100644 ld/testsuite/ld-elf/property-and-1.d create mode 100644 ld/testsuite/ld-elf/property-and-1.s create mode 100644 ld/testsuite/ld-elf/property-and-2.d create mode 100644 ld/testsuite/ld-elf/property-and-2.s create mode 100644 ld/testsuite/ld-elf/property-and-3.d create mode 100644 ld/testsuite/ld-elf/property-and-3.s create mode 100644 ld/testsuite/ld-elf/property-and-4.d create mode 100644 ld/testsuite/ld-elf/property-and-empty.s create mode 100644 ld/testsuite/ld-elf/property-or-1.d create mode 100644 ld/testsuite/ld-elf/property-or-1.s create mode 100644 ld/testsuite/ld-elf/property-or-2.d create mode 100644 ld/testsuite/ld-elf/property-or-2.s create mode 100644 ld/testsuite/ld-elf/property-or-3.d create mode 100644 ld/testsuite/ld-elf/property-or-3.s create mode 100644 ld/testsuite/ld-elf/property-or-4.d create mode 100644 ld/testsuite/ld-elf/property-or-empty.s diff --git a/bfd/elf-properties.c b/bfd/elf-properties.c index 491fa1aa8c6..6db618c91a0 100644 --- a/bfd/elf-properties.c +++ b/bfd/elf-properties.c @@ -178,6 +178,25 @@ _bfd_elf_parse_gnu_properties (bfd *abfd, Elf_Internal_Note *note) goto next; default: + if ((type >= GNU_PROPERTY_UINT32_AND_LO + && type <= GNU_PROPERTY_UINT32_AND_HI) + || (type >= GNU_PROPERTY_UINT32_OR_LO + && type <= GNU_PROPERTY_UINT32_OR_HI)) + { + if (datasz != 4) + { + _bfd_error_handler + (_("error: %pB: <corrupt property (0x%x) size: 0x%x>"), + abfd, type, datasz); + /* Clear all properties. */ + elf_properties (abfd) = NULL; + return FALSE; + } + prop = _bfd_elf_get_property (abfd, type, datasz); + prop->u.number |= bfd_h_get_32 (abfd, ptr); + prop->pr_kind = property_number; + goto next; + } break; } } @@ -203,6 +222,8 @@ elf_merge_gnu_properties (struct bfd_link_info *info, bfd *abfd, bfd *bbfd, { const struct elf_backend_data *bed = get_elf_backend_data (abfd); unsigned int pr_type = aprop != NULL ? aprop->pr_type : bprop->pr_type; + unsigned int number; + bfd_boolean updated; if (bed->merge_gnu_properties != NULL && pr_type >= GNU_PROPERTY_LOPROC @@ -229,6 +250,75 @@ elf_merge_gnu_properties (struct bfd_link_info *info, bfd *abfd, bfd *bbfd, return aprop == NULL; default: + updated = FALSE; + if (pr_type >= GNU_PROPERTY_UINT32_OR_LO + && pr_type <= GNU_PROPERTY_UINT32_OR_HI) + { + if (aprop != NULL && bprop != NULL) + { + 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; + } + 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; + } + } + return updated; + } + else if (pr_type >= GNU_PROPERTY_UINT32_AND_LO + && pr_type <= GNU_PROPERTY_UINT32_AND_HI) + { + /* Only one of APROP and BPROP can be NULL: + 1. APROP & BPROP when both APROP and BPROP aren't NULL. + 2. If APROP is NULL, remove x86 feature. + 3. Otherwise, do nothing. + */ + if (aprop != NULL && bprop != NULL) + { + number = aprop->u.number; + aprop->u.number = number & bprop->u.number; + 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 + { + /* There should be no AND properties since some input + doesn't have them. */ + if (aprop != NULL) + { + aprop->pr_kind = property_remove; + updated = TRUE; + } + } + return updated; + } + /* Never should happen. */ abort (); } diff --git a/binutils/readelf.c b/binutils/readelf.c index 5df51086226..be87767072a 100644 --- a/binutils/readelf.c +++ b/binutils/readelf.c @@ -19048,6 +19048,21 @@ print_gnu_property_note (Filedata * filedata, Elf_Internal_Note * pnote) goto next; default: + if ((type >= GNU_PROPERTY_UINT32_AND_LO + && type <= GNU_PROPERTY_UINT32_AND_HI) + || (type >= GNU_PROPERTY_UINT32_OR_LO + && type <= GNU_PROPERTY_UINT32_OR_HI)) + { + if (type <= GNU_PROPERTY_UINT32_AND_HI) + printf (_("UINT32_AND (%#x): "), type); + else + printf (_("UINT32_OR (%#x): "), type); + if (datasz != 4) + printf (_("<corrupt length: %#x> "), datasz); + else + printf ("%#x", (unsigned int) byte_get (ptr, 4)); + goto next; + } break; } } diff --git a/include/elf/common.h b/include/elf/common.h index e7d55ae0782..a3b7db8bc43 100644 --- a/include/elf/common.h +++ b/include/elf/common.h @@ -766,6 +766,16 @@ #define GNU_PROPERTY_STACK_SIZE 1 #define GNU_PROPERTY_NO_COPY_ON_PROTECTED 2 +/* A 4-byte unsigned integer property: A bit is set if it is set in all + relocatable inputs. */ +#define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 +#define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff + +/* A 4-byte unsigned integer property: A bit is set if it is set in any + relocatable inputs. */ +#define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 +#define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff + /* Processor-specific semantics, lo */ #define GNU_PROPERTY_LOPROC 0xc0000000 /* Processor-specific semantics, hi */ diff --git a/ld/testsuite/ld-elf/property-and-1.d b/ld/testsuite/ld-elf/property-and-1.d new file mode 100644 index 00000000000..4caf18c2000 --- /dev/null +++ b/ld/testsuite/ld-elf/property-and-1.d @@ -0,0 +1,7 @@ +#source: empty.s +#source: property-and-1.s +#as: +#ld: -shared +#readelf: -n +#xfail: ![check_shared_lib_support] + diff --git a/ld/testsuite/ld-elf/property-and-1.s b/ld/testsuite/ld-elf/property-and-1.s new file mode 100644 index 00000000000..3cff33da2d9 --- /dev/null +++ b/ld/testsuite/ld-elf/property-and-1.s @@ -0,0 +1,15 @@ + .section ".note.gnu.property", "a" + .p2align ALIGN + .long 1f - 0f /* name length */ + .long 5f - 2f /* data length */ + .long 5 /* note type */ +0: .asciz "GNU" /* vendor name */ +1: + .p2align ALIGN +2: .long 0xb0007fff /* pr_type. */ + .long 4f - 3f /* pr_datasz. */ +3: + .long 0x3 +4: + .p2align ALIGN +5: diff --git a/ld/testsuite/ld-elf/property-and-2.d b/ld/testsuite/ld-elf/property-and-2.d new file mode 100644 index 00000000000..2229243e275 --- /dev/null +++ b/ld/testsuite/ld-elf/property-and-2.d @@ -0,0 +1,8 @@ +#source: property-and-1.s +#source: empty.s +#source: property-and-2.s +#as: +#ld: -shared +#readelf: -n +#xfail: ![check_shared_lib_support] + diff --git a/ld/testsuite/ld-elf/property-and-2.s b/ld/testsuite/ld-elf/property-and-2.s new file mode 100644 index 00000000000..7149cb2d52b --- /dev/null +++ b/ld/testsuite/ld-elf/property-and-2.s @@ -0,0 +1,15 @@ + .section ".note.gnu.property", "a" + .p2align ALIGN + .long 1f - 0f /* name length */ + .long 5f - 2f /* data length */ + .long 5 /* note type */ +0: .asciz "GNU" /* vendor name */ +1: + .p2align ALIGN +2: .long 0xb0007fff /* pr_type. */ + .long 4f - 3f /* pr_datasz. */ +3: + .long 0x101 +4: + .p2align ALIGN +5: diff --git a/ld/testsuite/ld-elf/property-and-3.d b/ld/testsuite/ld-elf/property-and-3.d new file mode 100644 index 00000000000..fc9134441c3 --- /dev/null +++ b/ld/testsuite/ld-elf/property-and-3.d @@ -0,0 +1,8 @@ +#source: property-and-1.s +#source: property-and-empty.s +#source: property-and-2.s +#as: +#ld: -shared +#readelf: -n +#xfail: ![check_shared_lib_support] + diff --git a/ld/testsuite/ld-elf/property-and-3.s b/ld/testsuite/ld-elf/property-and-3.s new file mode 100644 index 00000000000..2838c9aef30 --- /dev/null +++ b/ld/testsuite/ld-elf/property-and-3.s @@ -0,0 +1,15 @@ + .section ".note.gnu.property", "a" + .p2align ALIGN + .long 1f - 0f /* name length */ + .long 5f - 2f /* data length */ + .long 5 /* note type */ +0: .asciz "GNU" /* vendor name */ +1: + .p2align ALIGN +2: .long 0xb0007fff /* pr_type. */ + .long 4f - 3f /* pr_datasz. */ +3: + .long 0x1001 +4: + .p2align ALIGN +5: diff --git a/ld/testsuite/ld-elf/property-and-4.d b/ld/testsuite/ld-elf/property-and-4.d new file mode 100644 index 00000000000..84bf404383f --- /dev/null +++ b/ld/testsuite/ld-elf/property-and-4.d @@ -0,0 +1,12 @@ +#source: property-and-1.s +#source: property-and-2.s +#source: property-and-3.s +#as: +#ld: -shared +#readelf: -n +#xfail: ![check_shared_lib_support] + +Displaying notes found in: .note.gnu.property +[ ]+Owner[ ]+Data size[ ]+Description + GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0 + Properties: UINT32_AND \(0xb0007fff\): 0x1 diff --git a/ld/testsuite/ld-elf/property-and-empty.s b/ld/testsuite/ld-elf/property-and-empty.s new file mode 100644 index 00000000000..02669adf1f8 --- /dev/null +++ b/ld/testsuite/ld-elf/property-and-empty.s @@ -0,0 +1,15 @@ + .section ".note.gnu.property", "a" + .p2align ALIGN + .long 1f - 0f /* name length */ + .long 5f - 2f /* data length */ + .long 5 /* note type */ +0: .asciz "GNU" /* vendor name */ +1: + .p2align ALIGN +2: .long 0xb0007fff /* pr_type. */ + .long 4f - 3f /* pr_datasz. */ +3: + .long 0x0 +4: + .p2align ALIGN +5: diff --git a/ld/testsuite/ld-elf/property-or-1.d b/ld/testsuite/ld-elf/property-or-1.d new file mode 100644 index 00000000000..f5392c42cf9 --- /dev/null +++ b/ld/testsuite/ld-elf/property-or-1.d @@ -0,0 +1,11 @@ +#source: empty.s +#source: property-or-1.s +#as: +#ld: -shared +#readelf: -n +#xfail: ![check_shared_lib_support] + +Displaying notes found in: .note.gnu.property +[ ]+Owner[ ]+Data size[ ]+Description + GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0 + Properties: UINT32_OR \(0xb000ffff\): 0x3 diff --git a/ld/testsuite/ld-elf/property-or-1.s b/ld/testsuite/ld-elf/property-or-1.s new file mode 100644 index 00000000000..a4714180c17 --- /dev/null +++ b/ld/testsuite/ld-elf/property-or-1.s @@ -0,0 +1,15 @@ + .section ".note.gnu.property", "a" + .p2align ALIGN + .long 1f - 0f /* name length */ + .long 5f - 2f /* data length */ + .long 5 /* note type */ +0: .asciz "GNU" /* vendor name */ +1: + .p2align ALIGN +2: .long 0xb000ffff /* pr_type. */ + .long 4f - 3f /* pr_datasz. */ +3: + .long 0x3 +4: + .p2align ALIGN +5: diff --git a/ld/testsuite/ld-elf/property-or-2.d b/ld/testsuite/ld-elf/property-or-2.d new file mode 100644 index 00000000000..85b754833cb --- /dev/null +++ b/ld/testsuite/ld-elf/property-or-2.d @@ -0,0 +1,12 @@ +#source: property-or-1.s +#source: empty.s +#source: property-or-2.s +#as: +#ld: -shared +#readelf: -n +#xfail: ![check_shared_lib_support] + +Displaying notes found in: .note.gnu.property +[ ]+Owner[ ]+Data size[ ]+Description + GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0 + Properties: UINT32_OR \(0xb000ffff\): 0x103 diff --git a/ld/testsuite/ld-elf/property-or-2.s b/ld/testsuite/ld-elf/property-or-2.s new file mode 100644 index 00000000000..a26047dab32 --- /dev/null +++ b/ld/testsuite/ld-elf/property-or-2.s @@ -0,0 +1,15 @@ + .section ".note.gnu.property", "a" + .p2align ALIGN + .long 1f - 0f /* name length */ + .long 5f - 2f /* data length */ + .long 5 /* note type */ +0: .asciz "GNU" /* vendor name */ +1: + .p2align ALIGN +2: .long 0xb000ffff /* pr_type. */ + .long 4f - 3f /* pr_datasz. */ +3: + .long 0x101 +4: + .p2align ALIGN +5: diff --git a/ld/testsuite/ld-elf/property-or-3.d b/ld/testsuite/ld-elf/property-or-3.d new file mode 100644 index 00000000000..2d687db4a61 --- /dev/null +++ b/ld/testsuite/ld-elf/property-or-3.d @@ -0,0 +1,12 @@ +#source: property-or-1.s +#source: property-and-empty.s +#source: property-or-2.s +#as: +#ld: -shared +#readelf: -n +#xfail: ![check_shared_lib_support] + +Displaying notes found in: .note.gnu.property +[ ]+Owner[ ]+Data size[ ]+Description + GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0 + Properties: UINT32_OR \(0xb000ffff\): 0x103 diff --git a/ld/testsuite/ld-elf/property-or-3.s b/ld/testsuite/ld-elf/property-or-3.s new file mode 100644 index 00000000000..d3e7367ea49 --- /dev/null +++ b/ld/testsuite/ld-elf/property-or-3.s @@ -0,0 +1,15 @@ + .section ".note.gnu.property", "a" + .p2align ALIGN + .long 1f - 0f /* name length */ + .long 5f - 2f /* data length */ + .long 5 /* note type */ +0: .asciz "GNU" /* vendor name */ +1: + .p2align ALIGN +2: .long 0xb000ffff /* pr_type. */ + .long 4f - 3f /* pr_datasz. */ +3: + .long 0x1001 +4: + .p2align ALIGN +5: diff --git a/ld/testsuite/ld-elf/property-or-4.d b/ld/testsuite/ld-elf/property-or-4.d new file mode 100644 index 00000000000..fee22b155c6 --- /dev/null +++ b/ld/testsuite/ld-elf/property-or-4.d @@ -0,0 +1,12 @@ +#source: property-or-1.s +#source: property-or-2.s +#source: property-or-3.s +#as: +#ld: -shared +#readelf: -n +#xfail: ![check_shared_lib_support] + +Displaying notes found in: .note.gnu.property +[ ]+Owner[ ]+Data size[ ]+Description + GNU 0x[0-9a-f]+ NT_GNU_PROPERTY_TYPE_0 + Properties: UINT32_OR \(0xb000ffff\): 0x1103 diff --git a/ld/testsuite/ld-elf/property-or-empty.s b/ld/testsuite/ld-elf/property-or-empty.s new file mode 100644 index 00000000000..f37e1dc7d69 --- /dev/null +++ b/ld/testsuite/ld-elf/property-or-empty.s @@ -0,0 +1,15 @@ + .section ".note.gnu.property", "a" + .p2align ALIGN + .long 1f - 0f /* name length */ + .long 5f - 2f /* data length */ + .long 5 /* note type */ +0: .asciz "GNU" /* vendor name */ +1: + .p2align ALIGN +2: .long 0xb000ffff /* pr_type. */ + .long 4f - 3f /* pr_datasz. */ +3: + .long 0x0 +4: + .p2align ALIGN +5: -- 2.29.2 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX 2021-01-21 15:02 ` H.J. Lu @ 2021-01-21 21:42 ` Fangrui Song 2021-04-17 12:48 ` H.J. Lu 2021-06-17 18:59 ` H.J. Lu 1 sibling, 1 reply; 8+ messages in thread From: Fangrui Song @ 2021-01-21 21:42 UTC (permalink / raw) To: H.J. Lu Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev On 2021-01-21, H.J. Lu via Gnu-gabi wrote: >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools@gmail.com> wrote: >> >> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI >> >> #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 >> #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff >> >> 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. >> >> If the bit is 1, all input relocatables have the feature. If the >> bit is 0 or the property is missing, the info is unknown. >> >> 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI >> >> #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 >> #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff >> >> 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, the info is unknown. >> >> The PDF is at >> >> https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf >> >> -- >> H.J. > >Here is the binutils patch to implement it. > >-- >H.J. Hi, H.J. Thank you for CCing llvm-dev:) In the past various GNU ABI proposals went unnoticed by LLVM folks who don't happen to subscribe to GNU lists. (A lot! I personally subscribe to some lists and check the discussion just in case I miss something important:) ) I have researched a bit and observed that the following GNU_PROPERTY values are currently used by compilers/linkers: Bitwise OR for relocatable links. Bitwise AND for executable/shared object links. * GNU_PROPERTY_X86_FEATURE_1_AND = GNU_PROPERTY_X86_UINT32_AND_LO + 0, * used by Intel Indirect branch tracking and Shadow Stack * GNU_PROPERTY_AARCH64_FEATURE_1_AND, used by AArch64 Branch Target * Identification and Pointer Authentication Bitwise OR for all links. * GNU_PROPERTY_X86_ISA_1_NEEDED = GNU_PROPERTY_X86_UINT32_OR_LO + 2, * used by GCC -mneeded (for -march=x86-64-v[234]) There appear to be another type of AND/OR bits which are not defined in ABIs (AFAICT): * GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + 2 * GNU_PROPERTY_X86_FEATURE_2_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + * 1 I think generalizing the AND/OR idea to all architectures probably requires us to think about these questions: * What's the impending usage of the generic AND/OR ranges? ifunc? :) * Does the concept generalize well to other architectures? If we * consider AArch64/x86 FEATURE_1_AND to be the same thing, the current * usage is purely x86 specific. * Is AND/OR encoding expressive enough to represent the required states? * I've asked two folks and they expressed concerns. I think the three * AND/OR usage above speak for themselves. * Szabolcs Nagy mentioned that GNU_PROPERTY is an OS-specific mechanism * (GNU), but the features are oftentimes arch specific which make sense * to other OSes or bare-metal. * Szabolcs: Do we need any versioning mechanism? The feature selection and compatibility checking mechanism has some overlap with GNU/arch-specific attributes (e.g .ARM.attributes, .riscv.attributes). If I understand correctly, GNU_PROPERTY has an associated program header so it can be checked by loaders (kernel/ld.so/emulator) while Attributes don't have program headers so they are largely assembler/linker protocols. In an inflexible way that such feature bits can affect observable states to loaders as well, e.g. .ARM.attributes can affect e_flags (soft/hard float). .MIPS.abiflags has an associated program header PT_MIPS_ABIFLAGS (I know nearly nothing about mips) Some thoughts from mips folks would be useful. Last, I think a feature selection and compatibility checking mechanism is assuredly useful, but whether the current AND/OR scheme can perfectly satisfy that goal I am unsure. Having the proposal is a very good start, though:) Thanks a lot for driving the discussion:) ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX 2021-01-21 21:42 ` Fangrui Song @ 2021-04-17 12:48 ` H.J. Lu 2021-04-17 18:25 ` Fangrui Song 0 siblings, 1 reply; 8+ messages in thread From: H.J. Lu @ 2021-04-17 12:48 UTC (permalink / raw) To: Fangrui Song Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song <i@maskray.me> wrote: > > On 2021-01-21, H.J. Lu via Gnu-gabi wrote: > >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools@gmail.com> wrote: > >> > >> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > >> > >> #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 > >> #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > >> > >> 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. > >> > >> If the bit is 1, all input relocatables have the feature. If the > >> bit is 0 or the property is missing, the info is unknown. > >> > >> 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI > >> > >> #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 > >> #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff > >> > >> 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, the info is unknown. > >> > >> The PDF is at > >> > >> https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf > >> > >> -- > >> H.J. > > > >Here is the binutils patch to implement it. > > > >-- > >H.J. > > Hi, H.J. > > Thank you for CCing llvm-dev:) In the past various GNU ABI proposals > went unnoticed by LLVM folks who don't happen to subscribe to GNU lists. > (A lot! I personally subscribe to some lists and check the discussion > just in case I miss something important:) ) > > I have researched a bit and observed that the following GNU_PROPERTY > values are currently used by compilers/linkers: > > Bitwise OR for relocatable links. Bitwise AND for executable/shared > object links. > > * GNU_PROPERTY_X86_FEATURE_1_AND = GNU_PROPERTY_X86_UINT32_AND_LO + 0, > * used by Intel Indirect branch tracking and Shadow Stack > * GNU_PROPERTY_AARCH64_FEATURE_1_AND, used by AArch64 Branch Target > * Identification and Pointer Authentication > > Bitwise OR for all links. > > * GNU_PROPERTY_X86_ISA_1_NEEDED = GNU_PROPERTY_X86_UINT32_OR_LO + 2, > * used by GCC -mneeded (for -march=x86-64-v[234]) > > There appear to be another type of AND/OR bits which are not defined in > ABIs (AFAICT): > > * GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + 2 > * GNU_PROPERTY_X86_FEATURE_2_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + > * 1 I have no use for these operations for generic targets. > > I think generalizing the AND/OR idea to all architectures probably > requires us to think about these questions: > > * What's the impending usage of the generic AND/OR ranges? ifunc? :) I'd like to add GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION: https://groups.google.com/g/x86-64-abi/c/DRvKxJ1AH3Q > * Does the concept generalize well to other architectures? If we It should work for GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION. > * consider AArch64/x86 FEATURE_1_AND to be the same thing, the current > * usage is purely x86 specific. > * Is AND/OR encoding expressive enough to represent the required states? For GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION, yes. > * I've asked two folks and they expressed concerns. I think the three > * AND/OR usage above speak for themselves. > * Szabolcs Nagy mentioned that GNU_PROPERTY is an OS-specific mechanism > * (GNU), but the features are oftentimes arch specific which make sense > * to other OSes or bare-metal. > * Szabolcs: Do we need any versioning mechanism? > > The feature selection and compatibility checking mechanism has some > overlap with GNU/arch-specific attributes (e.g .ARM.attributes, > .riscv.attributes). If I understand correctly, GNU_PROPERTY has an > associated program header so it can be checked by loaders > (kernel/ld.so/emulator) while Attributes don't have program headers so > they are largely assembler/linker protocols. In an inflexible way that > such feature bits can affect observable states to loaders as well, e.g. > .ARM.attributes can affect e_flags (soft/hard float). .MIPS.abiflags > has an associated program header PT_MIPS_ABIFLAGS (I know nearly nothing > about mips) Some thoughts from mips folks would be useful. > > Last, I think a feature selection and compatibility checking mechanism > is assuredly useful, but whether the current AND/OR scheme can perfectly > satisfy that goal I am unsure. Having the proposal is a very good start, > though:) Thanks a lot for driving the discussion:) My current ultimate goal is GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION with a compiler option, -fsingle-global-definition: 1. All accesses to protected definitions are local access. 2. In executable, all accesses to defined symbols are local access. 3. All global function pointers, whose function bodies aren't locally defined, must use GOT. 4. All read/write accesses to symbols, which aren't locally defined must, use GOT. 5. Branches to undefined symbols may use PLT. GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION will be enforced by assembler, linker and ld.so. -- H.J. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX 2021-04-17 12:48 ` H.J. Lu @ 2021-04-17 18:25 ` Fangrui Song 2021-04-17 19:05 ` H.J. Lu 0 siblings, 1 reply; 8+ messages in thread From: Fangrui Song @ 2021-04-17 18:25 UTC (permalink / raw) To: H.J. Lu Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev On 2021-04-17, H.J. Lu wrote: >On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song <i@maskray.me> wrote: >> >> On 2021-01-21, H.J. Lu via Gnu-gabi wrote: >> >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools@gmail.com> wrote: >> >> >> >> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI >> >> >> >> #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 >> >> #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff >> >> >> >> 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. >> >> >> >> If the bit is 1, all input relocatables have the feature. If the >> >> bit is 0 or the property is missing, the info is unknown. >> >> >> >> 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI >> >> >> >> #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 >> >> #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff >> >> >> >> 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, the info is unknown. >> >> >> >> The PDF is at >> >> >> >> https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf >> >> >> >> -- >> >> H.J. >> > >> >Here is the binutils patch to implement it. >> > >> >-- >> >H.J. >> >> Hi, H.J. >> >> Thank you for CCing llvm-dev:) In the past various GNU ABI proposals >> went unnoticed by LLVM folks who don't happen to subscribe to GNU lists. >> (A lot! I personally subscribe to some lists and check the discussion >> just in case I miss something important:) ) >> >> I have researched a bit and observed that the following GNU_PROPERTY >> values are currently used by compilers/linkers: >> >> Bitwise OR for relocatable links. Bitwise AND for executable/shared >> object links. >> >> * GNU_PROPERTY_X86_FEATURE_1_AND = GNU_PROPERTY_X86_UINT32_AND_LO + 0, >> * used by Intel Indirect branch tracking and Shadow Stack >> * GNU_PROPERTY_AARCH64_FEATURE_1_AND, used by AArch64 Branch Target >> * Identification and Pointer Authentication >> >> Bitwise OR for all links. >> >> * GNU_PROPERTY_X86_ISA_1_NEEDED = GNU_PROPERTY_X86_UINT32_OR_LO + 2, >> * used by GCC -mneeded (for -march=x86-64-v[234]) >> >> There appear to be another type of AND/OR bits which are not defined in >> ABIs (AFAICT): >> >> * GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + 2 >> * GNU_PROPERTY_X86_FEATURE_2_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + >> * 1 > >I have no use for these operations for generic targets. > >> >> I think generalizing the AND/OR idea to all architectures probably >> requires us to think about these questions: >> >> * What's the impending usage of the generic AND/OR ranges? ifunc? :) > >I'd like to add GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION: > >https://groups.google.com/g/x86-64-abi/c/DRvKxJ1AH3Q > >> * Does the concept generalize well to other architectures? If we > >It should work for GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION. > >> * consider AArch64/x86 FEATURE_1_AND to be the same thing, the current >> * usage is purely x86 specific. >> * Is AND/OR encoding expressive enough to represent the required states? > >For GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION, yes. > >> * I've asked two folks and they expressed concerns. I think the three >> * AND/OR usage above speak for themselves. >> * Szabolcs Nagy mentioned that GNU_PROPERTY is an OS-specific mechanism >> * (GNU), but the features are oftentimes arch specific which make sense >> * to other OSes or bare-metal. >> * Szabolcs: Do we need any versioning mechanism? >> >> The feature selection and compatibility checking mechanism has some >> overlap with GNU/arch-specific attributes (e.g .ARM.attributes, >> .riscv.attributes). If I understand correctly, GNU_PROPERTY has an >> associated program header so it can be checked by loaders >> (kernel/ld.so/emulator) while Attributes don't have program headers so >> they are largely assembler/linker protocols. In an inflexible way that >> such feature bits can affect observable states to loaders as well, e.g. >> .ARM.attributes can affect e_flags (soft/hard float). .MIPS.abiflags >> has an associated program header PT_MIPS_ABIFLAGS (I know nearly nothing >> about mips) Some thoughts from mips folks would be useful. >> >> Last, I think a feature selection and compatibility checking mechanism >> is assuredly useful, but whether the current AND/OR scheme can perfectly >> satisfy that goal I am unsure. Having the proposal is a very good start, >> though:) Thanks a lot for driving the discussion:) > >My current ultimate goal is GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION >with a compiler option, -fsingle-global-definition: > >1. All accesses to protected definitions are local access. >2. In executable, all accesses to defined symbols are local access. For other folks, I think https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected#protected-data-symbols-and-copy-relocations has summarized the current toolchain state and answered these questions. clang always emits local access for protected definitions so there should be no change. gcc does use GOT for protected data symbols but the scheme only works on i386 and x86-64. (arm and aarch64 have glibc support bot no binutils support IIUC). ld.lld always errors for copy relocations on protected data, and it will continue doing so, like gold (https://sourceware.org/bugzilla/show_bug.cgi?id=19823) So on the clang side, there is no needed change. On the GCC side, switching to local access for protected data symbols technically changes the behavior for i386 and x86-64 and might be considered an ABI change. But I'd argue that that does not matter because of three reasons: * clang i386 and x86-64 always emits local access for protected definitions * protected data+copy relocations never work on non-x86. (glibc has support for arm/aarch64 but binutils doesn't support it) * gold never supports protected data+copy relocations, even for x86 (https://sourceware.org/bugzilla/show_bug.cgi?id=19823) So if there is breakage (if any..), it must be x86 specific code using protected definitions, only built with gcc, not caring about traditional behavior (<~2015 or 2016), never supporting non-x86 architectures, only linkable with GNU ld (not gold), never supporting libc other than glibc. OK, I cannot even imagine who is doing this:) My blog post has mentioned what'd be great if gcc does: * GCC: add -f[no-]direct-access-external-data. * GCC: drop HAVE_LD_PIE_COPYRELOC in favor of -f[no-]direct-access-external-data. * GCC x86-64: default to GOT indirection for external data symbols in -fpie mode. * GCC or GNU as i386: emit R_386_PLT32 for branches to undefined function symbols. * GNU ld x86: disallow copy relocations on protected data symbols. (I think canonical PLT entries on protected symbols have been disallowed.) * GCC aarch64/arm/x86/...: allow direct access relocations on protected symbols in -fpic mode. * GNU ld aarch64/x86: allow direct access relocations on protected data symbols in -shared mode. I can understand that some GCC folks may like -f[no-]direct-access-external-data. That doesn't matter: just ignore -f[no-]direct-access-external-data (which gives the user a choice) and do the rest. >3. All global function pointers, whose function bodies aren't >locally defined, must use GOT. This should be the case for -fpie and -fpic. For -fno-pic, some users may want direct access and I think the compiler should give users a choice for compatibility. clang -fno-pic -fdirect-access-external-data (in -fno-pic mode, -fdirect-access-external-data is the default)does this perfectly. I know some GCC folks may not like the idea that the option name does not talk about function pointers.... That is unfortunate. >4. All read/write accesses to symbols, which aren't locally defined >must, use GOT. Ditto. >5. Branches to undefined symbols may use PLT. This has always been the case for most non-x86 architectures. For x86-64, the 2018 R_X86_64_PLT32 switch made this true. There is just a disagreement for R_386_PC32/R_386_PLT32 due to an ifunc diagnostic (which I think is not a big deal). Since i386 is becoming more and more irrelevant, this can be left unresolved. If you want to switch to R_386_PLT32, that'd certainly be great news to me:) >GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION will be enforced >by assembler, linker and ld.so. With the above, I think we won't break code without introducing a new gnu property. It is just that GCC/GNU ld need to take some actions which reflect traditional/non-x86 behaviors. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX 2021-04-17 18:25 ` Fangrui Song @ 2021-04-17 19:05 ` H.J. Lu 0 siblings, 0 replies; 8+ messages in thread From: H.J. Lu @ 2021-04-17 19:05 UTC (permalink / raw) To: Fangrui Song Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev On Sat, Apr 17, 2021 at 11:25 AM Fangrui Song <i@maskray.me> wrote: > > > On 2021-04-17, H.J. Lu wrote: > >On Thu, Jan 21, 2021 at 1:42 PM Fangrui Song <i@maskray.me> wrote: > >> > >> On 2021-01-21, H.J. Lu via Gnu-gabi wrote: > >> >On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools@gmail.com> wrote: > >> >> > >> >> 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > >> >> > >> >> #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 > >> >> #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > >> >> > >> >> 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. > >> >> > >> >> If the bit is 1, all input relocatables have the feature. If the > >> >> bit is 0 or the property is missing, the info is unknown. > >> >> > >> >> 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI > >> >> > >> >> #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 > >> >> #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff > >> >> > >> >> 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, the info is unknown. > >> >> > >> >> The PDF is at > >> >> > >> >> https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf > >> >> > >> >> -- > >> >> H.J. > >> > > >> >Here is the binutils patch to implement it. > >> > > >> >-- > >> >H.J. > >> > >> Hi, H.J. > >> > >> Thank you for CCing llvm-dev:) In the past various GNU ABI proposals > >> went unnoticed by LLVM folks who don't happen to subscribe to GNU lists. > >> (A lot! I personally subscribe to some lists and check the discussion > >> just in case I miss something important:) ) > >> > >> I have researched a bit and observed that the following GNU_PROPERTY > >> values are currently used by compilers/linkers: > >> > >> Bitwise OR for relocatable links. Bitwise AND for executable/shared > >> object links. > >> > >> * GNU_PROPERTY_X86_FEATURE_1_AND = GNU_PROPERTY_X86_UINT32_AND_LO + 0, > >> * used by Intel Indirect branch tracking and Shadow Stack > >> * GNU_PROPERTY_AARCH64_FEATURE_1_AND, used by AArch64 Branch Target > >> * Identification and Pointer Authentication > >> > >> Bitwise OR for all links. > >> > >> * GNU_PROPERTY_X86_ISA_1_NEEDED = GNU_PROPERTY_X86_UINT32_OR_LO + 2, > >> * used by GCC -mneeded (for -march=x86-64-v[234]) > >> > >> There appear to be another type of AND/OR bits which are not defined in > >> ABIs (AFAICT): > >> > >> * GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + 2 > >> * GNU_PROPERTY_X86_FEATURE_2_USED = GNU_PROPERTY_X86_UINT32_OR_AND_LO + > >> * 1 > > > >I have no use for these operations for generic targets. > > > >> > >> I think generalizing the AND/OR idea to all architectures probably > >> requires us to think about these questions: > >> > >> * What's the impending usage of the generic AND/OR ranges? ifunc? :) > > > >I'd like to add GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION: > > > >https://groups.google.com/g/x86-64-abi/c/DRvKxJ1AH3Q > > > >> * Does the concept generalize well to other architectures? If we > > > >It should work for GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION. > > > >> * consider AArch64/x86 FEATURE_1_AND to be the same thing, the current > >> * usage is purely x86 specific. > >> * Is AND/OR encoding expressive enough to represent the required states? > > > >For GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION, yes. > > > >> * I've asked two folks and they expressed concerns. I think the three > >> * AND/OR usage above speak for themselves. > >> * Szabolcs Nagy mentioned that GNU_PROPERTY is an OS-specific mechanism > >> * (GNU), but the features are oftentimes arch specific which make sense > >> * to other OSes or bare-metal. > >> * Szabolcs: Do we need any versioning mechanism? > >> > >> The feature selection and compatibility checking mechanism has some > >> overlap with GNU/arch-specific attributes (e.g .ARM.attributes, > >> .riscv.attributes). If I understand correctly, GNU_PROPERTY has an > >> associated program header so it can be checked by loaders > >> (kernel/ld.so/emulator) while Attributes don't have program headers so > >> they are largely assembler/linker protocols. In an inflexible way that > >> such feature bits can affect observable states to loaders as well, e.g. > >> .ARM.attributes can affect e_flags (soft/hard float). .MIPS.abiflags > >> has an associated program header PT_MIPS_ABIFLAGS (I know nearly nothing > >> about mips) Some thoughts from mips folks would be useful. > >> > >> Last, I think a feature selection and compatibility checking mechanism > >> is assuredly useful, but whether the current AND/OR scheme can perfectly > >> satisfy that goal I am unsure. Having the proposal is a very good start, > >> though:) Thanks a lot for driving the discussion:) > > > >My current ultimate goal is GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION > >with a compiler option, -fsingle-global-definition: > > > >1. All accesses to protected definitions are local access. > >2. In executable, all accesses to defined symbols are local access. > > For other folks, > I think > https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected#protected-data-symbols-and-copy-relocations > has summarized the current toolchain state and answered these questions. > > clang always emits local access for protected definitions so there > should be no change. > gcc does use GOT for protected data symbols but the scheme only works on > i386 and x86-64. > (arm and aarch64 have glibc support bot no binutils support IIUC). > ld.lld always errors for copy relocations on protected data, and it will > continue doing so, like gold (https://sourceware.org/bugzilla/show_bug.cgi?id=19823) > > So on the clang side, there is no needed change. > > > On the GCC side, switching to local access for protected data symbols > technically changes the behavior for i386 and x86-64 and might be considered an > ABI change. But I'd argue that that does not matter because of three reasons: > > * clang i386 and x86-64 always emits local access for protected definitions > * protected data+copy relocations never work on non-x86. (glibc has support for arm/aarch64 but binutils doesn't support it) > * gold never supports protected data+copy relocations, even for x86 (https://sourceware.org/bugzilla/show_bug.cgi?id=19823) > > So if there is breakage (if any..), it must be x86 specific code using > protected definitions, only built with gcc, not caring about traditional > behavior (<~2015 or 2016), never supporting non-x86 architectures, only > linkable with GNU ld (not gold), never supporting libc other than glibc. > > OK, I cannot even imagine who is doing this:) > > My blog post has mentioned what'd be great if gcc does: > > * GCC: add -f[no-]direct-access-external-data. > * GCC: drop HAVE_LD_PIE_COPYRELOC in favor of -f[no-]direct-access-external-data. > * GCC x86-64: default to GOT indirection for external data symbols in -fpie mode. > * GCC or GNU as i386: emit R_386_PLT32 for branches to undefined function symbols. > * GNU ld x86: disallow copy relocations on protected data symbols. (I think canonical PLT entries on protected symbols have been disallowed.) > * GCC aarch64/arm/x86/...: allow direct access relocations on protected symbols in -fpic mode. > * GNU ld aarch64/x86: allow direct access relocations on protected data symbols in -shared mode. > > I can understand that some GCC folks may like > -f[no-]direct-access-external-data. That doesn't matter: just ignore > -f[no-]direct-access-external-data (which gives the user a choice) and do the > rest. > > >3. All global function pointers, whose function bodies aren't > >locally defined, must use GOT. > > This should be the case for -fpie and -fpic. > > For -fno-pic, some users may want direct access and I think the compiler should > give users a choice for compatibility. > > clang -fno-pic -fdirect-access-external-data (in -fno-pic mode, > -fdirect-access-external-data is the default)does this perfectly. I know some > GCC folks may not like the idea that the option name does not talk about > function pointers.... That is unfortunate. > > >4. All read/write accesses to symbols, which aren't locally defined > >must, use GOT. > > Ditto. > > >5. Branches to undefined symbols may use PLT. > > This has always been the case for most non-x86 architectures. > For x86-64, the 2018 R_X86_64_PLT32 switch made this true. > > There is just a disagreement for R_386_PC32/R_386_PLT32 due to an ifunc > diagnostic (which I think is not a big deal). Since i386 is becoming > more and more irrelevant, this can be left unresolved. If you want to > switch to R_386_PLT32, that'd certainly be great news to me:) > > >GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION will be enforced > >by assembler, linker and ld.so. > > With the above, I think we won't break code without introducing a new > gnu property. It is just that GCC/GNU ld need to take some actions > which reflect traditional/non-x86 behaviors. There are special codes in ld.so to handle STV_PROTECTED: commit 62da1e3b00b51383ffa7efc89d8addda0502e107 Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Mar 31 05:15:43 2015 -0700 Add ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA to x86 With copy relocation, address of protected data defined in the shared library may be external. When there is a relocation against the protected data symbol within the shared library, we need to check if we should skip the definition in the executable copied from the protected data. This patch adds ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA and defines it for x86. If ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA isn't 0, do_lookup_x will skip the data definition in the executable from copy reloc. commit 6aa29abe9fab81e153d6232edf4ba048ac7d0b6e Author: Ulrich Drepper <drepper@redhat.com> Date: Mon May 22 16:33:19 2000 +0000 Update. 2000-05-21 H.J. Lu <hjl@gnu.org> * elf/do-lookup.h (do_lookup_versioned): Replace reloc_type paramete r with noexec and noplt parameter. (do_lookup): Likewise. * elf/dl-lookup.c (_dl_lookup_symbol): Change for new parameters of do_lookup. Support STV_PROTECTED. (_dl_lookup_symbol_skip): Likewise. (_dl_lookup_versioned_symbol): Likewise. (_dl_lookup_versioned_symbol_skip): Likewise. * elf/dl-reloc.c (RESOLVE): Check STB_LOCAL instead of ST_VISIBILITY. * elf/dl-runtime.c (profile_fixup): Fix a typo in comment. They and together with COPY relocation can be safely skipped only for GNU_PROPERTY_SINGLE_GLOBAL_DEFINITION binaries. -- H.J. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX 2021-01-21 15:02 ` H.J. Lu 2021-01-21 21:42 ` Fangrui Song @ 2021-06-17 18:59 ` H.J. Lu 1 sibling, 0 replies; 8+ messages in thread From: H.J. Lu @ 2021-06-17 18:59 UTC (permalink / raw) To: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > > > > #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 > > #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > > > > 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. > > > > If the bit is 1, all input relocatables have the feature. If the > > bit is 0 or the property is missing, the info is unknown. > > > > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI > > > > #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 > > #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff > > > > 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, the info is unknown. > > > > The PDF is at > > > > https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf > > > > -- > > H.J. > > Here is the binutils patch to implement it. > If there are no objections, I will check it in tomorrow. -- H.J. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-09-27 15:23 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-09-27 14:22 RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX GNU gABI gnu-gabi -- strict thread matches above, loose matches on Subject: below -- 2021-01-13 17:06 H.J. Lu 2021-01-21 15:02 ` H.J. Lu 2021-01-21 21:42 ` Fangrui Song 2021-04-17 12:48 ` H.J. Lu 2021-04-17 18:25 ` Fangrui Song 2021-04-17 19:05 ` H.J. Lu 2021-06-17 18:59 ` H.J. Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).