public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
* 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-06-18 15:38 ` RFC: Add GNU_PROPERTY_1_NEEDED H.J. Lu
  0 siblings, 2 replies; 22+ 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] 22+ messages in thread

* Re: RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-01-13 17:06 RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX 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
  2021-06-18 15:38 ` RFC: Add GNU_PROPERTY_1_NEEDED H.J. Lu
  1 sibling, 2 replies; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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
  2021-06-17 19:38     ` [llvm-dev] " Fangrui Song
  1 sibling, 1 reply; 22+ 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] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-17 18:59   ` H.J. Lu
@ 2021-06-17 19:38     ` Fangrui Song
  2021-06-17 19:45       ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: Fangrui Song @ 2021-06-17 19:38 UTC (permalink / raw)
  To: H.J. Lu
  Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

On 2021-06-17, H.J. Lu via llvm-dev wrote:
>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.

How to use AND in practice?
Are you going to add .note.gnu.property to all of crt1.o crti.o
crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
files written in assembly?

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

If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
very kind of you if you can collect more use cases before generalizing
this into a non-arch-specific GNU PROPERTY.

The "copy relocations on protected data symbols" thing is x86 specific
and only applies with gcc+GNU ld+glibc.
Non-x86 architectures don't have this thing.
gold doesn't have this thing.
clang doesn't have this thing.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-17 19:38     ` [llvm-dev] " Fangrui Song
@ 2021-06-17 19:45       ` H.J. Lu
  2021-06-17 20:25         ` Fāng-ruì Sòng
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2021-06-17 19:45 UTC (permalink / raw)
  To: Fangrui Song
  Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray@google.com> wrote:
>
> On 2021-06-17, H.J. Lu via llvm-dev wrote:
> >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.
>
> How to use AND in practice?
> Are you going to add .note.gnu.property to all of crt1.o crti.o
> crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> files written in assembly?
>
> >> > 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.
>
> If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> very kind of you if you can collect more use cases before generalizing
> this into a non-arch-specific GNU PROPERTY.
>
> The "copy relocations on protected data symbols" thing is x86 specific
> and only applies with gcc+GNU ld+glibc.
> Non-x86 architectures don't have this thing.
> gold doesn't have this thing.
> clang doesn't have this thing.

It will be used to remove copy relocation and implement canonical function
pointers, which will benefit protected data and function.

-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-17 19:45       ` H.J. Lu
@ 2021-06-17 20:25         ` Fāng-ruì Sòng
  2021-06-17 23:01           ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: Fāng-ruì Sòng @ 2021-06-17 20:25 UTC (permalink / raw)
  To: H.J. Lu
  Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray@google.com> wrote:
> >
> > On 2021-06-17, H.J. Lu via llvm-dev wrote:
> > >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.
> >
> > How to use AND in practice?
> > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> > files written in assembly?
> >
> > >> > 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.
> >
> > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> > very kind of you if you can collect more use cases before generalizing
> > this into a non-arch-specific GNU PROPERTY.
> >
> > The "copy relocations on protected data symbols" thing is x86 specific
> > and only applies with gcc+GNU ld+glibc.
> > Non-x86 architectures don't have this thing.
> > gold doesn't have this thing.
> > clang doesn't have this thing.
>
> It will be used to remove copy relocation and implement canonical function
> pointers, which will benefit protected data and function.

The action items in
https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
can be applied without a GNU PROPERTY.

If we want to enforce the link-time check that a shared object is no longer
compatible with copy relocations, just make the shared object's non-weak
definitions protected, and add a GNU ld diagnostic like gold
(https://sourceware.org/bugzilla/show_bug.cgi?id=19823)

---

For functions,

On x86-64, gcc -fpic has been using  leaq    addr()(%rip), %rax since at least
4.1.2 (oldest gcc I can find on godbolt):

  __attribute__((visibility("protected")))
  void *addr() { return (void*)addr; }

  // a protected non-definition declaration is the same.

  // while asm(".protected addr") can use GOT, it is super rare if ever exists
  // outside glibc elf/vis*.c

I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
the same diagnostic:

  relocation R_X86_64_PC32 against protected function `addr' can not
be used when making a shared object

I think we can assert that taking the address of a protected function
never works with GNU ld.
So no compatibility concern.
Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
doesn't need any GNU PROPERTY.

---

For variables, if an object file/archive member does not have GNU PROPERTY, do
you consider it incompatible with "single global definition"? That is why I
mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members
written in assembly.

If you consider such an object compatible with "single global definition", I
don't see why a GNU PROPERTY is needed.

If you consider such an object incompatible with "single global definition", I
don't see how "single global definition" benefits can be claimed giving so many
prebuilt object files without GNU PROPERTY.

If we still want "absolutely no copy relocation for -fno-pic", just use GOT for
default visibility external data access
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112)
Some architectures may not like it (i386/ppc32), just leave them behind.
Modern architectures can do it. When things get matured, add a ld warning,
then add a ld.so warning. When things get more matured, change the warnings to
errors.

Such changes should use a mechanism similar to glibc LD_DYNAMIC_WEAK (weak can
preempt global) and Solaris LD_BREADTH (breadth-first order based dependency
order) and LD_NODIRECT (direct bindings). At some point, introduce a behavior
change.  I don't think how an explicit marker can improve the compatibility
story. The conceived compatibility issues likely don't really exist for
functions. For copy relocations, I think we may need to wait an extended period
of time.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-17 20:25         ` Fāng-ruì Sòng
@ 2021-06-17 23:01           ` H.J. Lu
  2021-06-18  0:06             ` Fāng-ruì Sòng
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2021-06-17 23:01 UTC (permalink / raw)
  To: Fāng-ruì Sòng
  Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray@google.com> wrote:
> > >
> > > On 2021-06-17, H.J. Lu via llvm-dev wrote:
> > > >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.
> > >
> > > How to use AND in practice?
> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> > > files written in assembly?
> > >
> > > >> > 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.
> > >
> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> > > very kind of you if you can collect more use cases before generalizing
> > > this into a non-arch-specific GNU PROPERTY.
> > >
> > > The "copy relocations on protected data symbols" thing is x86 specific
> > > and only applies with gcc+GNU ld+glibc.
> > > Non-x86 architectures don't have this thing.
> > > gold doesn't have this thing.
> > > clang doesn't have this thing.
> >
> > It will be used to remove copy relocation and implement canonical function
> > pointers, which will benefit protected data and function.
>
> The action items in
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
> can be applied without a GNU PROPERTY.
>
> If we want to enforce the link-time check that a shared object is no longer
> compatible with copy relocations, just make the shared object's non-weak
> definitions protected, and add a GNU ld diagnostic like gold
> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
>
> ---
>
> For functions,
>
> On x86-64, gcc -fpic has been using  leaq    addr()(%rip), %rax since at least
> 4.1.2 (oldest gcc I can find on godbolt):
>
>   __attribute__((visibility("protected")))
>   void *addr() { return (void*)addr; }
>
>   // a protected non-definition declaration is the same.
>
>   // while asm(".protected addr") can use GOT, it is super rare if ever exists
>   // outside glibc elf/vis*.c
>
> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
> the same diagnostic:
>
>   relocation R_X86_64_PC32 against protected function `addr' can not
> be used when making a shared object
>
> I think we can assert that taking the address of a protected function
> never works with GNU ld.
> So no compatibility concern.
> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
> doesn't need any GNU PROPERTY.
>
> ---
>
> For variables, if an object file/archive member does not have GNU PROPERTY, do
> you consider it incompatible with "single global definition"? That is why I
> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members
> written in assembly.
>
> If you consider such an object compatible with "single global definition", I
> don't see why a GNU PROPERTY is needed.
>
> If you consider such an object incompatible with "single global definition", I
> don't see how "single global definition" benefits can be claimed giving so many
> prebuilt object files without GNU PROPERTY.

Please see the slides in

https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8

which includes

Dynamic Linker for Single Global Definition
• Check the single global definition marker on all components, the executable
and its dependency shared libraries.
• Issue an error/warning if the marker is not consistent on all components.
• Disallow copy relocation against definition in the shared library with the
marker.
• For systems without function descriptor:
• Disallow function pointer reference in executable without the marker to the
definition with the STV_PROTECTED visibility in a shared library with
the marker.
• Use the address of the function body as function pointer on functions with the
STV_PROTECTED visibility, which are defined in shared libraries with the marker.

This provides the capability to detect the ABI change at run-time as well as
optimize for STV_PROTECTED symbol lookup.

My linker implementation is at

https://gitlab.com/x86-binutils/binutils-gdb/-/tree/users/hjl/property/master

I will implement the dynamic linker change.

> If we still want "absolutely no copy relocation for -fno-pic", just use GOT for
> default visibility external data access
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112)
> Some architectures may not like it (i386/ppc32), just leave them behind.
> Modern architectures can do it. When things get matured, add a ld warning,
> then add a ld.so warning. When things get more matured, change the warnings to
> errors.
>
> Such changes should use a mechanism similar to glibc LD_DYNAMIC_WEAK (weak can
> preempt global) and Solaris LD_BREADTH (breadth-first order based dependency
> order) and LD_NODIRECT (direct bindings). At some point, introduce a behavior
> change.  I don't think how an explicit marker can improve the compatibility
> story. The conceived compatibility issues likely don't really exist for

The compatibility issue does exist.  Please see the linker tests I added.

> functions. For copy relocations, I think we may need to wait an extended period
> of time.

That is what the single global definition marker is used for.

-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-17 23:01           ` H.J. Lu
@ 2021-06-18  0:06             ` Fāng-ruì Sòng
  2021-06-18  0:24               ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: Fāng-ruì Sòng @ 2021-06-18  0:06 UTC (permalink / raw)
  To: H.J. Lu
  Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

On 2021-06-17, H.J. Lu wrote:
>On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>>
>> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>> >
>> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray@google.com> wrote:
>> > >
>> > > On 2021-06-17, H.J. Lu via llvm-dev wrote:
>> > > >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.
>> > >
>> > > How to use AND in practice?
>> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
>> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
>> > > files written in assembly?
>> > >
>> > > >> > 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.
>> > >
>> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
>> > > very kind of you if you can collect more use cases before generalizing
>> > > this into a non-arch-specific GNU PROPERTY.
>> > >
>> > > The "copy relocations on protected data symbols" thing is x86 specific
>> > > and only applies with gcc+GNU ld+glibc.
>> > > Non-x86 architectures don't have this thing.
>> > > gold doesn't have this thing.
>> > > clang doesn't have this thing.
>> >
>> > It will be used to remove copy relocation and implement canonical function
>> > pointers, which will benefit protected data and function.
>>
>> The action items in
>> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
>> can be applied without a GNU PROPERTY.
>>
>> If we want to enforce the link-time check that a shared object is no longer
>> compatible with copy relocations, just make the shared object's non-weak
>> definitions protected, and add a GNU ld diagnostic like gold
>> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
>>
>> ---
>>
>> For functions,
>>
>> On x86-64, gcc -fpic has been using  leaq    addr()(%rip), %rax since at least
>> 4.1.2 (oldest gcc I can find on godbolt):
>>
>>   __attribute__((visibility("protected")))
>>   void *addr() { return (void*)addr; }
>>
>>   // a protected non-definition declaration is the same.
>>
>>   // while asm(".protected addr") can use GOT, it is super rare if ever exists
>>   // outside glibc elf/vis*.c
>>
>> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
>> the same diagnostic:
>>
>>   relocation R_X86_64_PC32 against protected function `addr' can not
>> be used when making a shared object
>>
>> I think we can assert that taking the address of a protected function
>> never works with GNU ld.
>> So no compatibility concern.
>> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
>> doesn't need any GNU PROPERTY.
>>
>> ---
>>
>> For variables, if an object file/archive member does not have GNU PROPERTY, do
>> you consider it incompatible with "single global definition"? That is why I
>> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members
>> written in assembly.
>>
>> If you consider such an object compatible with "single global definition", I
>> don't see why a GNU PROPERTY is needed.
>>
>> If you consider such an object incompatible with "single global definition", I
>> don't see how "single global definition" benefits can be claimed giving so many
>> prebuilt object files without GNU PROPERTY.
>
>Please see the slides in
>
>https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8
>
>which includes
>
>Dynamic Linker for Single Global Definition
>• Check the single global definition marker on all components, the executable
>and its dependency shared libraries.
>• Issue an error/warning if the marker is not consistent on all components.

This is not appealing from a compatibility point of view.
It is common that a system has mixed shared objects:

-fsingle-global-definition => a.so (marker value 1)
no -fsingle-global-definition => b.so (marker value 0 or no marker)

Issuing a warning will be annoying.

If glibc x86 wants to deprecate copy relocations support,
just fix the compilers(*)/GNU ld. -fno-pic dynamically linked executables are
becoming rarer on modern Linux distributions,
When the toolchain support is sufficiently mature (e.g. ld has warned/errored),
add an opt-opt `LD_` style environment variable and let glibc ld.so warn, then gradually
make it an error.

* I can fix Clang -fno-pic at any time. I haven't done that just to be compatible with gcc -fno-pic.

>• Disallow copy relocation against definition in the shared library with the
>marker.
>• For systems without function descriptor:

>• Disallow function pointer reference in executable without the marker to the
>definition with the STV_PROTECTED visibility in a shared library with
>the marker.
>• Use the address of the function body as function pointer on functions with the
>STV_PROTECTED visibility, which are defined in shared libraries with the marker.

I have provided the solutions in my previous message.

>This provides the capability to detect the ABI change at run-time as well as
>optimize for STV_PROTECTED symbol lookup.

STV_PROTECTED symbols should not need a compiler option or a GNU PROPERTY to work (efficiently).

As my previous message mentioned (gcc 4.1.2~now; GNU ld 2.11~now),
protected function addresses in a shared object likely never work, at
least for the past 20 years.

For protected data, x86 copy relocations did not work prior to circa 2015.
It never works on non-x86, gold, clang, or non-glibc.
And I doubt any project uses protected data given that its sole purpose is for
optimization while GCC 5 added unneeded indirection.

Ulrich Drepper did add elf/vis* tests into glibc in 2000, but they use
artificial inline asm .protected which does not reflect any reality.

GNU ld -shared for a protected symbol

* x86-64: broken direct access relocation, unneeded GLOB_DAT
* aarch64: broken direct access relocation, unneeded GLOB_DAT
* arm: unneeded GLOB_DAT for STT_OBJECT
* ppc32: unneeded GLOB_DAT for STT_OBJECT
* ppc64le: good, no GLOB_DAT
* mips64el: good, no GLOB_DAT
* riscv64: good, no GLOB_DAT

Perhaps for binutils in 2000, more ports had unneeded dynamic relocations which
made the elf/vis* tests more plausible. But the fragile support (acked by
multiple glibc maintainers, including Adhemerval/Carlos/Szabolcs) is definitely
largely irrelevant nowadays.

>My linker implementation is at
>
>https://gitlab.com/x86-binutils/binutils-gdb/-/tree/users/hjl/property/master
>
>I will implement the dynamic linker change.
>
>> If we still want "absolutely no copy relocation for -fno-pic", just use GOT for
>> default visibility external data access
>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112)
>> Some architectures may not like it (i386/ppc32), just leave them behind.
>> Modern architectures can do it. When things get matured, add a ld warning,
>> then add a ld.so warning. When things get more matured, change the warnings to
>> errors.
>>
>> Such changes should use a mechanism similar to glibc LD_DYNAMIC_WEAK (weak can
>> preempt global) and Solaris LD_BREADTH (breadth-first order based dependency
>> order) and LD_NODIRECT (direct bindings). At some point, introduce a behavior
>> change.  I don't think how an explicit marker can improve the compatibility
>> story. The conceived compatibility issues likely don't really exist for
>
>The compatibility issue does exist.  Please see the linker tests I added.

ld-x86-64/protecte-func-* are artificial assembly which do not match the reality.
They are cases where never work or aren't really promised to work before.

>> functions. For copy relocations, I think we may need to wait an extended period
>> of time.
>
>That is what the single global definition marker is used for.

See my first paragraph why a GNU PROPERTY may not be a good compatibility solution.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-18  0:06             ` Fāng-ruì Sòng
@ 2021-06-18  0:24               ` H.J. Lu
  2021-06-18  0:49                 ` Fāng-ruì Sòng
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2021-06-18  0:24 UTC (permalink / raw)
  To: Fāng-ruì Sòng
  Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On 2021-06-17, H.J. Lu wrote:
> >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> >>
> >> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >> >
> >> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray@google.com> wrote:
> >> > >
> >> > > On 2021-06-17, H.J. Lu via llvm-dev wrote:
> >> > > >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.
> >> > >
> >> > > How to use AND in practice?
> >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
> >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> >> > > files written in assembly?
> >> > >
> >> > > >> > 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.
> >> > >
> >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> >> > > very kind of you if you can collect more use cases before generalizing
> >> > > this into a non-arch-specific GNU PROPERTY.
> >> > >
> >> > > The "copy relocations on protected data symbols" thing is x86 specific
> >> > > and only applies with gcc+GNU ld+glibc.
> >> > > Non-x86 architectures don't have this thing.
> >> > > gold doesn't have this thing.
> >> > > clang doesn't have this thing.
> >> >
> >> > It will be used to remove copy relocation and implement canonical function
> >> > pointers, which will benefit protected data and function.
> >>
> >> The action items in
> >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
> >> can be applied without a GNU PROPERTY.
> >>
> >> If we want to enforce the link-time check that a shared object is no longer
> >> compatible with copy relocations, just make the shared object's non-weak
> >> definitions protected, and add a GNU ld diagnostic like gold
> >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
> >>
> >> ---
> >>
> >> For functions,
> >>
> >> On x86-64, gcc -fpic has been using  leaq    addr()(%rip), %rax since at least
> >> 4.1.2 (oldest gcc I can find on godbolt):
> >>
> >>   __attribute__((visibility("protected")))
> >>   void *addr() { return (void*)addr; }
> >>
> >>   // a protected non-definition declaration is the same.
> >>
> >>   // while asm(".protected addr") can use GOT, it is super rare if ever exists
> >>   // outside glibc elf/vis*.c
> >>
> >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
> >> the same diagnostic:
> >>
> >>   relocation R_X86_64_PC32 against protected function `addr' can not
> >> be used when making a shared object
> >>
> >> I think we can assert that taking the address of a protected function
> >> never works with GNU ld.
> >> So no compatibility concern.
> >> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
> >> doesn't need any GNU PROPERTY.
> >>
> >> ---
> >>
> >> For variables, if an object file/archive member does not have GNU PROPERTY, do
> >> you consider it incompatible with "single global definition"? That is why I
> >> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members
> >> written in assembly.
> >>
> >> If you consider such an object compatible with "single global definition", I
> >> don't see why a GNU PROPERTY is needed.
> >>
> >> If you consider such an object incompatible with "single global definition", I
> >> don't see how "single global definition" benefits can be claimed giving so many
> >> prebuilt object files without GNU PROPERTY.
> >
> >Please see the slides in
> >
> >https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8
> >
> >which includes
> >
> >Dynamic Linker for Single Global Definition
> >• Check the single global definition marker on all components, the executable
> >and its dependency shared libraries.
> >• Issue an error/warning if the marker is not consistent on all components.
>
> This is not appealing from a compatibility point of view.
> It is common that a system has mixed shared objects:
>
> -fsingle-global-definition => a.so (marker value 1)
> no -fsingle-global-definition => b.so (marker value 0 or no marker)
> Issuing a warning will be annoying.
>

I updated my proposal to

Dynamic Linker for Single Global Definition
• Check the single global definition marker on all components, the executable
and its dependency shared libraries.
• Disallow copy relocation against definition with the STV_PROTECTED
visibility in the shared library with the marker.
• For systems without function descriptor:
• Disallow non-GOT function pointer reference in executable without
the marker to the
definition with the STV_PROTECTED visibility in a shared library with
the marker.
• Use the address of the function body as function pointer on functions with the
STV_PROTECTED visibility, which are defined in shared libraries with the marker.

-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-18  0:24               ` H.J. Lu
@ 2021-06-18  0:49                 ` Fāng-ruì Sòng
  2021-06-18  2:40                   ` H.J. Lu
  2021-06-18  2:45                   ` H.J. Lu
  0 siblings, 2 replies; 22+ messages in thread
From: Fāng-ruì Sòng @ 2021-06-18  0:49 UTC (permalink / raw)
  To: H.J. Lu
  Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> >
> > On 2021-06-17, H.J. Lu wrote:
> > >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > >>
> > >> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >> >
> > >> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray@google.com> wrote:
> > >> > >
> > >> > > On 2021-06-17, H.J. Lu via llvm-dev wrote:
> > >> > > >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.
> > >> > >
> > >> > > How to use AND in practice?
> > >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> > >> > > files written in assembly?
> > >> > >
> > >> > > >> > 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.
> > >> > >
> > >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> > >> > > very kind of you if you can collect more use cases before generalizing
> > >> > > this into a non-arch-specific GNU PROPERTY.
> > >> > >
> > >> > > The "copy relocations on protected data symbols" thing is x86 specific
> > >> > > and only applies with gcc+GNU ld+glibc.
> > >> > > Non-x86 architectures don't have this thing.
> > >> > > gold doesn't have this thing.
> > >> > > clang doesn't have this thing.
> > >> >
> > >> > It will be used to remove copy relocation and implement canonical function
> > >> > pointers, which will benefit protected data and function.
> > >>
> > >> The action items in
> > >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
> > >> can be applied without a GNU PROPERTY.
> > >>
> > >> If we want to enforce the link-time check that a shared object is no longer
> > >> compatible with copy relocations, just make the shared object's non-weak
> > >> definitions protected, and add a GNU ld diagnostic like gold
> > >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
> > >>
> > >> ---
> > >>
> > >> For functions,
> > >>
> > >> On x86-64, gcc -fpic has been using  leaq    addr()(%rip), %rax since at least
> > >> 4.1.2 (oldest gcc I can find on godbolt):
> > >>
> > >>   __attribute__((visibility("protected")))
> > >>   void *addr() { return (void*)addr; }
> > >>
> > >>   // a protected non-definition declaration is the same.
> > >>
> > >>   // while asm(".protected addr") can use GOT, it is super rare if ever exists
> > >>   // outside glibc elf/vis*.c
> > >>
> > >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
> > >> the same diagnostic:
> > >>
> > >>   relocation R_X86_64_PC32 against protected function `addr' can not
> > >> be used when making a shared object
> > >>
> > >> I think we can assert that taking the address of a protected function
> > >> never works with GNU ld.
> > >> So no compatibility concern.
> > >> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
> > >> doesn't need any GNU PROPERTY.
> > >>
> > >> ---
> > >>
> > >> For variables, if an object file/archive member does not have GNU PROPERTY, do
> > >> you consider it incompatible with "single global definition"? That is why I
> > >> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members
> > >> written in assembly.
> > >>
> > >> If you consider such an object compatible with "single global definition", I
> > >> don't see why a GNU PROPERTY is needed.
> > >>
> > >> If you consider such an object incompatible with "single global definition", I
> > >> don't see how "single global definition" benefits can be claimed giving so many
> > >> prebuilt object files without GNU PROPERTY.
> > >
> > >Please see the slides in
> > >
> > >https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8
> > >
> > >which includes
> > >
> > >Dynamic Linker for Single Global Definition
> > >• Check the single global definition marker on all components, the executable
> > >and its dependency shared libraries.
> > >• Issue an error/warning if the marker is not consistent on all components.
> >
> > This is not appealing from a compatibility point of view.
> > It is common that a system has mixed shared objects:
> >
> > -fsingle-global-definition => a.so (marker value 1)
> > no -fsingle-global-definition => b.so (marker value 0 or no marker)
> > Issuing a warning will be annoying.
> >
>
> I updated my proposal to
>
> Dynamic Linker for Single Global Definition
> • Check the single global definition marker on all components, the executable
> and its dependency shared libraries.

I find that I forgot (in so many of my previous messages) to mention
that the name "single global definition" may give a false impression.
For example, a dynamic STV_DEFAULT STB_WEAK/STB_GLOBAL symbol defined
in a shared object can still be interposed.

> • Disallow copy relocation against definition with the STV_PROTECTED
> visibility in the shared library with the marker.

If this is for GNU ld x86 only, I'm fine with it:)

gold and ld.lld just emit an error unconditionally. I think non-x86
GNU ld ports which never support "copy relocations on protected data
symbols" may want to make the diagnostic unconditional as well.
Well, while (Michael Matz and ) I think compatibility check for "copy
relocations on protected data symbols" is over-engineering (and
Alan/Cary think it was a mistake), if you still want to add it, it is
fine for me...
For Clang, I hope we will not emit such a property, because Clang
never supports the "copy relocations on protected data symbols"
scheme.

> • For systems without function descriptor:
> • Disallow non-GOT function pointer reference in executable without
> the marker to the
> definition with the STV_PROTECTED visibility in a shared library with
> the marker.

I think this can be unconditional, because the "pointer equality for
STV_PROTECTED function address in -shared" case hasn't been working
for GNU ld for at least 20 years...
Many ports don't even produce a dynamic relocation.
I don't mind if you add it just for symmetry, but it just feels unneeded.

> • Use the address of the function body as function pointer on functions with the
> STV_PROTECTED visibility, which are defined in shared libraries with the marker.


>
> --
> H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-18  0:49                 ` Fāng-ruì Sòng
@ 2021-06-18  2:40                   ` H.J. Lu
  2021-06-21 14:35                     ` Michael Matz
  2021-06-18  2:45                   ` H.J. Lu
  1 sibling, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2021-06-18  2:40 UTC (permalink / raw)
  To: Fāng-ruì Sòng
  Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

On Thu, Jun 17, 2021 at 5:49 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > >
> > > On 2021-06-17, H.J. Lu wrote:
> > > >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > >>
> > > >> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >> >
> > > >> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray@google.com> wrote:
> > > >> > >
> > > >> > > On 2021-06-17, H.J. Lu via llvm-dev wrote:
> > > >> > > >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.
> > > >> > >
> > > >> > > How to use AND in practice?
> > > >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > > >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> > > >> > > files written in assembly?
> > > >> > >
> > > >> > > >> > 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.
> > > >> > >
> > > >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> > > >> > > very kind of you if you can collect more use cases before generalizing
> > > >> > > this into a non-arch-specific GNU PROPERTY.
> > > >> > >
> > > >> > > The "copy relocations on protected data symbols" thing is x86 specific
> > > >> > > and only applies with gcc+GNU ld+glibc.
> > > >> > > Non-x86 architectures don't have this thing.
> > > >> > > gold doesn't have this thing.
> > > >> > > clang doesn't have this thing.
> > > >> >
> > > >> > It will be used to remove copy relocation and implement canonical function
> > > >> > pointers, which will benefit protected data and function.
> > > >>
> > > >> The action items in
> > > >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
> > > >> can be applied without a GNU PROPERTY.
> > > >>
> > > >> If we want to enforce the link-time check that a shared object is no longer
> > > >> compatible with copy relocations, just make the shared object's non-weak
> > > >> definitions protected, and add a GNU ld diagnostic like gold
> > > >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
> > > >>
> > > >> ---
> > > >>
> > > >> For functions,
> > > >>
> > > >> On x86-64, gcc -fpic has been using  leaq    addr()(%rip), %rax since at least
> > > >> 4.1.2 (oldest gcc I can find on godbolt):
> > > >>
> > > >>   __attribute__((visibility("protected")))
> > > >>   void *addr() { return (void*)addr; }
> > > >>
> > > >>   // a protected non-definition declaration is the same.
> > > >>
> > > >>   // while asm(".protected addr") can use GOT, it is super rare if ever exists
> > > >>   // outside glibc elf/vis*.c
> > > >>
> > > >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
> > > >> the same diagnostic:
> > > >>
> > > >>   relocation R_X86_64_PC32 against protected function `addr' can not
> > > >> be used when making a shared object
> > > >>
> > > >> I think we can assert that taking the address of a protected function
> > > >> never works with GNU ld.
> > > >> So no compatibility concern.
> > > >> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
> > > >> doesn't need any GNU PROPERTY.
> > > >>
> > > >> ---
> > > >>
> > > >> For variables, if an object file/archive member does not have GNU PROPERTY, do
> > > >> you consider it incompatible with "single global definition"? That is why I
> > > >> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members
> > > >> written in assembly.
> > > >>
> > > >> If you consider such an object compatible with "single global definition", I
> > > >> don't see why a GNU PROPERTY is needed.
> > > >>
> > > >> If you consider such an object incompatible with "single global definition", I
> > > >> don't see how "single global definition" benefits can be claimed giving so many
> > > >> prebuilt object files without GNU PROPERTY.
> > > >
> > > >Please see the slides in
> > > >
> > > >https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8
> > > >
> > > >which includes
> > > >
> > > >Dynamic Linker for Single Global Definition
> > > >• Check the single global definition marker on all components, the executable
> > > >and its dependency shared libraries.
> > > >• Issue an error/warning if the marker is not consistent on all components.
> > >
> > > This is not appealing from a compatibility point of view.
> > > It is common that a system has mixed shared objects:
> > >
> > > -fsingle-global-definition => a.so (marker value 1)
> > > no -fsingle-global-definition => b.so (marker value 0 or no marker)
> > > Issuing a warning will be annoying.
> > >
> >
> > I updated my proposal to
> >
> > Dynamic Linker for Single Global Definition
> > • Check the single global definition marker on all components, the executable
> > and its dependency shared libraries.
>
> I find that I forgot (in so many of my previous messages) to mention
> that the name "single global definition" may give a false impression.
> For example, a dynamic STV_DEFAULT STB_WEAK/STB_GLOBAL symbol defined
> in a shared object can still be interposed.
>
> > • Disallow copy relocation against definition with the STV_PROTECTED
> > visibility in the shared library with the marker.
>
> If this is for GNU ld x86 only, I'm fine with it:)
>
> gold and ld.lld just emit an error unconditionally. I think non-x86
> GNU ld ports which never support "copy relocations on protected data
> symbols" may want to make the diagnostic unconditional as well.
> Well, while (Michael Matz and ) I think compatibility check for "copy
> relocations on protected data symbols" is over-engineering (and
> Alan/Cary think it was a mistake), if you still want to add it, it is
> fine for me...
> For Clang, I hope we will not emit such a property, because Clang
> never supports the "copy relocations on protected data symbols"
> scheme.

The issue is that libfoo.so used in link-time can be different from
libfoo.so at run-time.   The symbol, foobar, in libfoo.so at link-time
has the default visibility.  But foobar in libfoo.so at run-time can be
protected.  ld.so should detect such cases which can lead to run-time
failures.

> > • For systems without function descriptor:
> > • Disallow non-GOT function pointer reference in executable without
> > the marker to the
> > definition with the STV_PROTECTED visibility in a shared library with
> > the marker.
>
> I think this can be unconditional, because the "pointer equality for
> STV_PROTECTED function address in -shared" case hasn't been working
> for GNU ld for at least 20 years...
> Many ports don't even produce a dynamic relocation.

True.  But see above.   You may not care about such use cases.  But I believe
that ld.so should not knowingly and silently allow such run-time
failure to happen.

> I don't mind if you add it just for symmetry, but it just feels unneeded.
>
> > • Use the address of the function body as function pointer on functions with the
> > STV_PROTECTED visibility, which are defined in shared libraries with the marker.
>
>
> >
> > --
> > H.J.



-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-18  0:49                 ` Fāng-ruì Sòng
  2021-06-18  2:40                   ` H.J. Lu
@ 2021-06-18  2:45                   ` H.J. Lu
  1 sibling, 0 replies; 22+ messages in thread
From: H.J. Lu @ 2021-06-18  2:45 UTC (permalink / raw)
  To: Fāng-ruì Sòng
  Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

On Thu, Jun 17, 2021 at 5:49 PM Fāng-ruì Sòng <maskray@google.com> wrote:
>
> On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> >
> > On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > >
> > > On 2021-06-17, H.J. Lu wrote:
> > > >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng <maskray@google.com> wrote:
> > > >>
> > > >> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools@gmail.com> wrote:
> > > >> >
> > > >> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray@google.com> wrote:
> > > >> > >
> > > >> > > On 2021-06-17, H.J. Lu via llvm-dev wrote:
> > > >> > > >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.
> > > >> > >
> > > >> > > How to use AND in practice?
> > > >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o
> > > >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object
> > > >> > > files written in assembly?
> > > >> > >
> > > >> > > >> > 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.
> > > >> > >
> > > >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be
> > > >> > > very kind of you if you can collect more use cases before generalizing
> > > >> > > this into a non-arch-specific GNU PROPERTY.
> > > >> > >
> > > >> > > The "copy relocations on protected data symbols" thing is x86 specific
> > > >> > > and only applies with gcc+GNU ld+glibc.
> > > >> > > Non-x86 architectures don't have this thing.
> > > >> > > gold doesn't have this thing.
> > > >> > > clang doesn't have this thing.
> > > >> >
> > > >> > It will be used to remove copy relocation and implement canonical function
> > > >> > pointers, which will benefit protected data and function.
> > > >>
> > > >> The action items in
> > > >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281
> > > >> can be applied without a GNU PROPERTY.
> > > >>
> > > >> If we want to enforce the link-time check that a shared object is no longer
> > > >> compatible with copy relocations, just make the shared object's non-weak
> > > >> definitions protected, and add a GNU ld diagnostic like gold
> > > >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823)
> > > >>
> > > >> ---
> > > >>
> > > >> For functions,
> > > >>
> > > >> On x86-64, gcc -fpic has been using  leaq    addr()(%rip), %rax since at least
> > > >> 4.1.2 (oldest gcc I can find on godbolt):
> > > >>
> > > >>   __attribute__((visibility("protected")))
> > > >>   void *addr() { return (void*)addr; }
> > > >>
> > > >>   // a protected non-definition declaration is the same.
> > > >>
> > > >>   // while asm(".protected addr") can use GOT, it is super rare if ever exists
> > > >>   // outside glibc elf/vis*.c
> > > >>
> > > >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have
> > > >> the same diagnostic:
> > > >>
> > > >>   relocation R_X86_64_PC32 against protected function `addr' can not
> > > >> be used when making a shared object
> > > >>
> > > >> I think we can assert that taking the address of a protected function
> > > >> never works with GNU ld.
> > > >> So no compatibility concern.
> > > >> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html)
> > > >> doesn't need any GNU PROPERTY.
> > > >>
> > > >> ---
> > > >>
> > > >> For variables, if an object file/archive member does not have GNU PROPERTY, do
> > > >> you consider it incompatible with "single global definition"? That is why I
> > > >> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members
> > > >> written in assembly.
> > > >>
> > > >> If you consider such an object compatible with "single global definition", I
> > > >> don't see why a GNU PROPERTY is needed.
> > > >>
> > > >> If you consider such an object incompatible with "single global definition", I
> > > >> don't see how "single global definition" benefits can be claimed giving so many
> > > >> prebuilt object files without GNU PROPERTY.
> > > >
> > > >Please see the slides in
> > > >
> > > >https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8
> > > >
> > > >which includes
> > > >
> > > >Dynamic Linker for Single Global Definition
> > > >• Check the single global definition marker on all components, the executable
> > > >and its dependency shared libraries.
> > > >• Issue an error/warning if the marker is not consistent on all components.
> > >
> > > This is not appealing from a compatibility point of view.
> > > It is common that a system has mixed shared objects:
> > >
> > > -fsingle-global-definition => a.so (marker value 1)
> > > no -fsingle-global-definition => b.so (marker value 0 or no marker)
> > > Issuing a warning will be annoying.
> > >
> >
> > I updated my proposal to
> >
> > Dynamic Linker for Single Global Definition
> > • Check the single global definition marker on all components, the executable
> > and its dependency shared libraries.
>
> I find that I forgot (in so many of my previous messages) to mention
> that the name "single global definition" may give a false impression.
> For example, a dynamic STV_DEFAULT STB_WEAK/STB_GLOBAL symbol defined
> in a shared object can still be interposed.
>

"single global definition" means that only one global definition will be used
at run-time.  It doesn't mean that there are no multiple symbols with the same
name.

H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* RFC: Add GNU_PROPERTY_1_NEEDED
  2021-01-13 17:06 RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX H.J. Lu
  2021-01-21 15:02 ` H.J. Lu
@ 2021-06-18 15:38 ` H.J. Lu
  2021-06-18 21:34   ` [llvm-dev] " Fangrui Song
  1 sibling, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2021-06-18 15:38 UTC (permalink / raw)
  To: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

Add GNU_PROPERTY_1_NEEDED:

 #define GNU_PROPERTY_1_NEEDED      GNU_PROPERTY_UINT32_OR_LO

to indicate the needed properties by the object file.

Add GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION:

 #define GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION  (1U << 0)

to indicate that the object file requires canonical function pointers and
cannot be used with copy relocation.

The PDF file is at

https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/9eca2f2defe62b0c5015bf2e3e8a9f05/Linux-gABI-1_needed-2021-06-18.pdf

-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_1_NEEDED
  2021-06-18 15:38 ` RFC: Add GNU_PROPERTY_1_NEEDED H.J. Lu
@ 2021-06-18 21:34   ` Fangrui Song
  2021-06-19  1:09     ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: Fangrui Song @ 2021-06-18 21:34 UTC (permalink / raw)
  To: H.J. Lu
  Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

On 2021-06-18, H.J. Lu via llvm-dev wrote:
>Add GNU_PROPERTY_1_NEEDED:
>
> #define GNU_PROPERTY_1_NEEDED      GNU_PROPERTY_UINT32_OR_LO
>
>to indicate the needed properties by the object file.
>

I am fine with this logical OR style usage. But see below, do we need it
for ld.so runtime check?

(As I mentioned previously, I do not know how an AND-style property can
be used/deployed if old object files without the .note.gnu.property is
considered to have a value of 0.)

>Add GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION:
>
> #define GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION  (1U << 0)
>
>to indicate that the object file requires canonical function pointers and
>cannot be used with copy relocation.

In https://sourceware.org/pipermail/gnu-gabi/2021q2/000481.html you gave
a rationale

"The issue is that libfoo.so used in link-time can be different from
  libfoo.so at run-time.   The symbol, foobar, in libfoo.so at link-time
  has the default visibility.  But foobar in libfoo.so at run-time can be
  protected.  ld.so should detect such cases which can lead to run-time
  failures."

First, I think such dynamic symbol visibility change is uncommon.

Second, if ld.so finds that a symbol lookup for (st_value==0
st_shndx==SHN_UNDEF) will bind to a STV_PROTECTED definition in a shared
object, can the diagnostic be moved there?
The compatibility property is per-symbol and the symbol lookup is a
perfect place for a diagnostic, like a symbol versioning error.


I guess GCC folks may get noticed if you start a thread adding
-fsingle-global-definition, otherwise many people who have opinions may
just ignore threads about GNU PROPERTY addition.

>
>The PDF file is at
>
>https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/9eca2f2defe62b0c5015bf2e3e8a9f05/Linux-gABI-1_needed-2021-06-18.pdf

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_1_NEEDED
  2021-06-18 21:34   ` [llvm-dev] " Fangrui Song
@ 2021-06-19  1:09     ` H.J. Lu
  0 siblings, 0 replies; 22+ messages in thread
From: H.J. Lu @ 2021-06-19  1:09 UTC (permalink / raw)
  To: Fangrui Song
  Cc: GNU gABI gnu-gabi, GCC Development, Binutils, GNU C Library, llvm-dev

On Fri, Jun 18, 2021 at 2:34 PM Fangrui Song <maskray@google.com> wrote:
>
> On 2021-06-18, H.J. Lu via llvm-dev wrote:
> >Add GNU_PROPERTY_1_NEEDED:
> >
> > #define GNU_PROPERTY_1_NEEDED      GNU_PROPERTY_UINT32_OR_LO
> >
> >to indicate the needed properties by the object file.
> >
>
> I am fine with this logical OR style usage. But see below, do we need it
> for ld.so runtime check?

I implemented run-time check on users/hjl/single-global/master branch:

https://gitlab.com/x86-glibc/glibc/-/commits/users/hjl/single-global/master

with tests:

[hjl@gnu-cfl-2 build-x86_64-linux]$ elf/tst-protected1a
copy relocation against non-copyable protected symbol=protected1 in
file=/export/build/gnu/tools-build/glibc-cet-gitlab/build-x86_64-linux/elf/tst-protected1moda.so
[hjl@gnu-cfl-2 build-x86_64-linux]$ elf/tst-protected2a
`protected1' in main and moda doesn't have the same address
non-canonical reference to canonical protected function
symbol=protected1 in
file=/export/build/gnu/tools-build/glibc-cet-gitlab/build-x86_64-linux/elf/tst-protected2moda.so
[hjl@gnu-cfl-2 build-x86_64-linux]$

I prefer these over random run-time failures.

> (As I mentioned previously, I do not know how an AND-style property can
> be used/deployed if old object files without the .note.gnu.property is
> considered to have a value of 0.)
>
> >Add GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION:
> >
> > #define GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION  (1U << 0)
> >
> >to indicate that the object file requires canonical function pointers and
> >cannot be used with copy relocation.
>
> In https://sourceware.org/pipermail/gnu-gabi/2021q2/000481.html you gave
> a rationale
>
> "The issue is that libfoo.so used in link-time can be different from
>   libfoo.so at run-time.   The symbol, foobar, in libfoo.so at link-time
>   has the default visibility.  But foobar in libfoo.so at run-time can be
>   protected.  ld.so should detect such cases which can lead to run-time
>   failures."
>
> First, I think such dynamic symbol visibility change is uncommon.

I can imagine that some libraries want to switch to protected symbols.

> Second, if ld.so finds that a symbol lookup for (st_value==0
> st_shndx==SHN_UNDEF) will bind to a STV_PROTECTED definition in a shared
> object, can the diagnostic be moved there?
> The compatibility property is per-symbol and the symbol lookup is a
> perfect place for a diagnostic, like a symbol versioning error.
>
>
> I guess GCC folks may get noticed if you start a thread adding
> -fsingle-global-definition, otherwise many people who have opinions may
> just ignore threads about GNU PROPERTY addition.

Binutils changes are at

https://gitlab.com/x86-binutils/binutils-gdb/-/tree/users/hjl/property/master

GCC changes are next.

> >
> >The PDF file is at
> >
> >https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/9eca2f2defe62b0c5015bf2e3e8a9f05/Linux-gABI-1_needed-2021-06-18.pdf



-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-18  2:40                   ` H.J. Lu
@ 2021-06-21 14:35                     ` Michael Matz
  2021-06-22 14:30                       ` H.J. Lu
  0 siblings, 1 reply; 22+ messages in thread
From: Michael Matz @ 2021-06-21 14:35 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Fāng-ruì Sòng, llvm-dev, GCC Development,
	GNU C Library, GNU gABI gnu-gabi, Binutils

Hello,

On Thu, 17 Jun 2021, H.J. Lu via Gcc wrote:

> > > • Disallow copy relocation against definition with the STV_PROTECTED
> > > visibility in the shared library with the marker.
> >
> > If this is for GNU ld x86 only, I'm fine with it:)
> >
> > gold and ld.lld just emit an error unconditionally. I think non-x86
> > GNU ld ports which never support "copy relocations on protected data
> > symbols" may want to make the diagnostic unconditional as well.
> > Well, while (Michael Matz and ) I think compatibility check for "copy
> > relocations on protected data symbols" is over-engineering (and
> > Alan/Cary think it was a mistake), if you still want to add it, it is
> > fine for me...
> > For Clang, I hope we will not emit such a property, because Clang
> > never supports the "copy relocations on protected data symbols"
> > scheme.
> 
> The issue is that libfoo.so used in link-time can be different from 
> libfoo.so at run-time.  The symbol, foobar, in libfoo.so at link-time 
> has the default visibility.  But foobar in libfoo.so at run-time can be 
> protected.  ld.so should detect such cases which can lead to run-time 
> failures.

Yes, but I think we can _unconditionally_ give an error in this case, even 
without a marker.  I view restricting visiblity of a symbol in furture 
versions of shared libraries to be an ABI change, hence it has to be 
something that either requires a soname bump or at the very least symbol 
versioning with the old version staying on default visibility.

Compare the situation to one where the old libfoo.so provided a symbol 
bar, and the new one doesn't (sort of very restricted visiblity).  ld.so 
will unconditionally give an error.  I don't see this situation materially 
different from bar's visibility be changed from default to protected.

> > I think this can be unconditional, because the "pointer equality for 
> > STV_PROTECTED function address in -shared" case hasn't been working 
> > for GNU ld for at least 20 years... Many ports don't even produce a 
> > dynamic relocation.
> 
> True.  But see above.  You may not care about such use cases.  But I 
> believe that ld.so should not knowingly and silently allow such run-time 
> failure to happen.

Agreed, but giving an error message unconditionally wouldn't be silent.


Ciao,
Michael.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-21 14:35                     ` Michael Matz
@ 2021-06-22 14:30                       ` H.J. Lu
  2021-06-22 14:54                         ` Michael Matz
  0 siblings, 1 reply; 22+ messages in thread
From: H.J. Lu @ 2021-06-22 14:30 UTC (permalink / raw)
  To: Michael Matz
  Cc: Fāng-ruì Sòng, llvm-dev, GCC Development,
	GNU C Library, GNU gABI gnu-gabi, Binutils

On Mon, Jun 21, 2021 at 7:36 AM Michael Matz <matz@suse.de> wrote:
>
> Hello,
>
> On Thu, 17 Jun 2021, H.J. Lu via Gcc wrote:
>
> > > > • Disallow copy relocation against definition with the STV_PROTECTED
> > > > visibility in the shared library with the marker.
> > >
> > > If this is for GNU ld x86 only, I'm fine with it:)
> > >
> > > gold and ld.lld just emit an error unconditionally. I think non-x86
> > > GNU ld ports which never support "copy relocations on protected data
> > > symbols" may want to make the diagnostic unconditional as well.
> > > Well, while (Michael Matz and ) I think compatibility check for "copy
> > > relocations on protected data symbols" is over-engineering (and
> > > Alan/Cary think it was a mistake), if you still want to add it, it is
> > > fine for me...
> > > For Clang, I hope we will not emit such a property, because Clang
> > > never supports the "copy relocations on protected data symbols"
> > > scheme.
> >
> > The issue is that libfoo.so used in link-time can be different from
> > libfoo.so at run-time.  The symbol, foobar, in libfoo.so at link-time
> > has the default visibility.  But foobar in libfoo.so at run-time can be
> > protected.  ld.so should detect such cases which can lead to run-time
> > failures.
>
> Yes, but I think we can _unconditionally_ give an error in this case, even
> without a marker.  I view restricting visiblity of a symbol in furture

Unconditionally issuing an error can be an option, but mandatory.
Otherwise working binary today will fail to run tomorrow.

> versions of shared libraries to be an ABI change, hence it has to be
> something that either requires a soname bump or at the very least symbol

To support existing binaries, we need a soname bump.

> versioning with the old version staying on default visibility.

Symbol versioning doesn't work here since both symbols are at
the same address.

> Compare the situation to one where the old libfoo.so provided a symbol
> bar, and the new one doesn't (sort of very restricted visiblity).  ld.so
> will unconditionally give an error.  I don't see this situation materially
> different from bar's visibility be changed from default to protected.
>
> > > I think this can be unconditional, because the "pointer equality for
> > > STV_PROTECTED function address in -shared" case hasn't been working
> > > for GNU ld for at least 20 years... Many ports don't even produce a
> > > dynamic relocation.
> >
> > True.  But see above.  You may not care about such use cases.  But I
> > believe that ld.so should not knowingly and silently allow such run-time
> > failure to happen.
>
> Agreed, but giving an error message unconditionally wouldn't be silent.
>
>
> Ciao,
> Michael.



-- 
H.J.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
  2021-06-22 14:30                       ` H.J. Lu
@ 2021-06-22 14:54                         ` Michael Matz
  0 siblings, 0 replies; 22+ messages in thread
From: Michael Matz @ 2021-06-22 14:54 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Fāng-ruì Sòng, llvm-dev, GCC Development,
	GNU C Library, GNU gABI gnu-gabi, Binutils

Hello,

On Tue, 22 Jun 2021, H.J. Lu wrote:

> > > The issue is that libfoo.so used in link-time can be different from
> > > libfoo.so at run-time.  The symbol, foobar, in libfoo.so at link-time
> > > has the default visibility.  But foobar in libfoo.so at run-time can be
> > > protected.  ld.so should detect such cases which can lead to run-time
> > > failures.
> >
> > Yes, but I think we can _unconditionally_ give an error in this case, even
> > without a marker.  I view restricting visiblity of a symbol in furture
> 
> Unconditionally issuing an error can be an option, but mandatory.
> Otherwise working binary today will fail to run tomorrow.

Like a binary that's working today will fail tomorrow if the updated 
shared lib simply removes a symbol from it's export without proper 
versioning.  I don't see a material difference.

> > versions of shared libraries to be an ABI change, hence it has to be
> > something that either requires a soname bump or at the very least symbol
> 
> To support existing binaries, we need a soname bump.
> 
> > versioning with the old version staying on default visibility.
> 
> Symbol versioning doesn't work here since both symbols are at
> the same address.

I don't see why the address should matter.  My point was that in the end 
the exported symbol table for such shared lib (where foobar was changed 
from default to protected visiblity) should have

 1: 12345 42 FUNC GLOBAL DEFAULT 1 foobar@Old
 2: 12345 42 FUNC GLOBAL PROTECTED 1 foobar@@New

This might require new GAS directives and compiler attributes (or might be 
expressible already).  References from within the shared library would 
need to continue going via the default visiblity symbol, so that it 
supports old binaries containing copy relocs, which just again points out 
that it's a bad idea to restrict visibility after the fact.

AFAICS your scheme also doesn't support old binaries with newly protected 
symbols in newer shared libs, so an (unconditional) error in such 
situation seems appropriate.  IOW: which scenario do you want to not error 
on when you want to make the error conditional?


Ciao,
Michael.

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2021-06-22 14:54 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-13 17:06 RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX 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
2021-06-17 19:38     ` [llvm-dev] " Fangrui Song
2021-06-17 19:45       ` H.J. Lu
2021-06-17 20:25         ` Fāng-ruì Sòng
2021-06-17 23:01           ` H.J. Lu
2021-06-18  0:06             ` Fāng-ruì Sòng
2021-06-18  0:24               ` H.J. Lu
2021-06-18  0:49                 ` Fāng-ruì Sòng
2021-06-18  2:40                   ` H.J. Lu
2021-06-21 14:35                     ` Michael Matz
2021-06-22 14:30                       ` H.J. Lu
2021-06-22 14:54                         ` Michael Matz
2021-06-18  2:45                   ` H.J. Lu
2021-06-18 15:38 ` RFC: Add GNU_PROPERTY_1_NEEDED H.J. Lu
2021-06-18 21:34   ` [llvm-dev] " Fangrui Song
2021-06-19  1:09     ` 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).