public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
* RFC: Add GNU_PROPERTY_NEED_PHDRS
@ 2018-01-01  0:00 H.J. Lu
  2018-01-01  0:00 ` Michael Matz
  0 siblings, 1 reply; 18+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Rich Felker
  Cc: Cary Coutant, Carlos O'Donell, Florian Weimer, Szabolcs Nagy,
	Jan Beulich, Binutils, gnu-gabi

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]

On Fri, Sep 28, 2018 at 7:30 AM, Rich Felker <dalias@libc.org> wrote:
> On Fri, Sep 28, 2018 at 06:42:52AM -0700, H.J. Lu wrote:
>
>> Dynamic loader has no problem.  The problem is kernel passes
>> AT_PHDR to main, which points to the unmmaped address.   We can
>> ask for kernel change or make kernel happy.
>
> Kernel change does not help because nobody is obligated to use a new
> kernel. Binutils would be producing binaries that don't work on
> existing kernels (if the note hack were reverted or if similar changes
> were added to other archs without a note hack; right now of course
> it's working again).

True.

>> My current .note.gnu.property patch only works for x86.   We can
>> add
>>
>> #define GNU_PROPERTY_PHDRS 3
>>
>> so that it can be used for all targets.
>
> What would this do?
>

These are what I have in mind.


-- 
H.J.

[-- Attachment #2: 0001-Don-t-add-GNU_PROPERTY_X86_FEATURE_2_NEEDED.patch --]
[-- Type: text/x-patch, Size: 4576 bytes --]

From ad8ef2328b42ee040bac68d9736867a0551497b5 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Tue, 25 Sep 2018 12:33:59 -0700
Subject: [PATCH 1/2] Don't add GNU_PROPERTY_X86_FEATURE_2_NEEDED

FAIL: Run PR ld/23428 test
---
 bfd/elfxx-x86.c                              | 45 --------------------
 ld/testsuite/ld-i386/property-x86-4a.d       |  3 +-
 ld/testsuite/ld-x86-64/property-x86-4a-x32.d |  3 +-
 ld/testsuite/ld-x86-64/property-x86-4a.d     |  3 +-
 4 files changed, 3 insertions(+), 51 deletions(-)

diff --git a/bfd/elfxx-x86.c b/bfd/elfxx-x86.c
index fc99b28c07..05f5c6a2f9 100644
--- a/bfd/elfxx-x86.c
+++ b/bfd/elfxx-x86.c
@@ -2542,7 +2542,6 @@ _bfd_x86_elf_link_setup_gnu_properties
   const struct elf_backend_data *bed;
   unsigned int class_align = ABI_64_P (info->output_bfd) ? 3 : 2;
   unsigned int got_align;
-  bfd_boolean has_text = FALSE;
 
   features = 0;
   if (info->ibt)
@@ -2557,14 +2556,6 @@ _bfd_x86_elf_link_setup_gnu_properties
     if (bfd_get_flavour (pbfd) == bfd_target_elf_flavour
 	&& bfd_count_sections (pbfd) != 0)
       {
-	if (!has_text)
-	  {
-	    /* Check if there is no non-empty text section.  */
-	    sec = bfd_get_section_by_name (pbfd, ".text");
-	    if (sec != NULL && sec->size != 0)
-	      has_text = TRUE;
-	  }
-
 	ebfd = pbfd;
 
 	if (elf_properties (pbfd) != NULL)
@@ -2590,42 +2581,6 @@ _bfd_x86_elf_link_setup_gnu_properties
 	  prop->u.number |= features;
 	  prop->pr_kind = property_number;
 	}
-      else if (has_text
-	       && elf_tdata (info->output_bfd)->o->build_id.sec == NULL
-	       && !htab->elf.dynamic_sections_created
-	       && !info->traditional_format
-	       && (info->output_bfd->flags & D_PAGED) != 0
-	       && info->separate_code)
-	{
-	  /* If the separate code program header is needed, make sure
-	     that the first read-only PT_LOAD segment has no code by
-	     adding a GNU_PROPERTY_X86_FEATURE_2_NEEDED note.  */
-	  elf_property_list *list;
-	  bfd_boolean need_property = TRUE;
-
-	  for (list = elf_properties (ebfd); list; list = list->next)
-	    {
-	      unsigned int pr_type = list->property.pr_type;
-	      if (pr_type == GNU_PROPERTY_STACK_SIZE
-		  || pr_type == GNU_PROPERTY_NO_COPY_ON_PROTECTED
-		  || pr_type == GNU_PROPERTY_X86_COMPAT_ISA_1_NEEDED
-		  || (pr_type >= GNU_PROPERTY_X86_UINT32_OR_LO
-		      && pr_type <= GNU_PROPERTY_X86_UINT32_OR_HI))
-		{
-		  /* These properties won't be removed during merging.  */
-		  need_property = FALSE;
-		  break;
-		}
-	    }
-
-	  if (need_property)
-	    {
-	      prop = _bfd_elf_get_property
-		(ebfd, GNU_PROPERTY_X86_FEATURE_2_NEEDED, 4);
-	      prop->u.number = GNU_PROPERTY_X86_FEATURE_2_X86;
-	      prop->pr_kind = property_number;
-	    }
-	}
 
       /* Create the GNU property note section if needed.  */
       if (prop != NULL && pbfd == NULL)
diff --git a/ld/testsuite/ld-i386/property-x86-4a.d b/ld/testsuite/ld-i386/property-x86-4a.d
index 8ab0115cdd..5e2b4689f8 100644
--- a/ld/testsuite/ld-i386/property-x86-4a.d
+++ b/ld/testsuite/ld-i386/property-x86-4a.d
@@ -6,8 +6,7 @@
 
 Displaying notes found in: .note.gnu.property
   Owner                 Data size	Description
-  GNU                  0x0000002c	NT_GNU_PROPERTY_TYPE_0
+  GNU                  0x00000020	NT_GNU_PROPERTY_TYPE_0
       Properties: no copy on protected 
-	x86 feature needed: x86
 	x86 ISA used: <None>
 	x86 feature used: x86
diff --git a/ld/testsuite/ld-x86-64/property-x86-4a-x32.d b/ld/testsuite/ld-x86-64/property-x86-4a-x32.d
index 9dd6e3540e..76f74e5ded 100644
--- a/ld/testsuite/ld-x86-64/property-x86-4a-x32.d
+++ b/ld/testsuite/ld-x86-64/property-x86-4a-x32.d
@@ -6,8 +6,7 @@
 
 Displaying notes found in: .note.gnu.property
   Owner                 Data size	Description
-  GNU                  0x0000002c	NT_GNU_PROPERTY_TYPE_0
+  GNU                  0x00000020	NT_GNU_PROPERTY_TYPE_0
       Properties: no copy on protected 
-	x86 feature needed: x86
 	x86 ISA used: <None>
 	x86 feature used: x86
diff --git a/ld/testsuite/ld-x86-64/property-x86-4a.d b/ld/testsuite/ld-x86-64/property-x86-4a.d
index 4dc87acd56..e76be796a6 100644
--- a/ld/testsuite/ld-x86-64/property-x86-4a.d
+++ b/ld/testsuite/ld-x86-64/property-x86-4a.d
@@ -6,8 +6,7 @@
 
 Displaying notes found in: .note.gnu.property
   Owner                 Data size	Description
-  GNU                  0x00000038	NT_GNU_PROPERTY_TYPE_0
+  GNU                  0x00000028	NT_GNU_PROPERTY_TYPE_0
       Properties: no copy on protected 
-	x86 feature needed: x86
 	x86 ISA used: <None>
 	x86 feature used: x86
-- 
2.17.1


[-- Attachment #3: 0002-Add-GNU_PROPERTY_NEED_PHDRS.patch --]
[-- Type: text/x-patch, Size: 6841 bytes --]

From fe965abfab6908a2de0ea888cdfbaa0352d9ce02 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Fri, 28 Sep 2018 15:58:09 -0700
Subject: [PATCH 2/2] Add GNU_PROPERTY_NEED_PHDRS

---
 bfd/elf-properties.c | 127 +++++++++++++++++++++++++++++++++++--------
 binutils/readelf.c   |   6 ++
 include/elf/common.h |   1 +
 3 files changed, 110 insertions(+), 24 deletions(-)

diff --git a/bfd/elf-properties.c b/bfd/elf-properties.c
index 861db73170..d92ffc3ce5 100644
--- a/bfd/elf-properties.c
+++ b/bfd/elf-properties.c
@@ -177,6 +177,19 @@ bad_size:
 	      prop->pr_kind = property_number;
 	      goto next;
 
+	    case GNU_PROPERTY_NEED_PHDRS:
+	      if (datasz != 0)
+		{
+		  _bfd_error_handler
+		    (_("warning: %pB: corrupt need phdrs size: 0x%x"),
+		     abfd, datasz);
+		  /* Clear all properties.  */
+		  elf_properties (abfd) = NULL;
+		  return FALSE;
+		}
+	      /* Ignore GNU_PROPERTY_NEED_PHDRS in input files.  */
+	      goto next;
+
 	    default:
 	      break;
 	    }
@@ -224,6 +237,7 @@ elf_merge_gnu_properties (struct bfd_link_info *info, bfd *abfd,
       /* FALLTHROUGH */
 
     case GNU_PROPERTY_NO_COPY_ON_PROTECTED:
+    case GNU_PROPERTY_NEED_PHDRS:
       /* Return TRUE if APROP is NULL to indicate that BPROP should
 	 be added to ABFD.  */
       return aprop == NULL;
@@ -414,34 +428,62 @@ _bfd_elf_link_setup_gnu_properties (struct bfd_link_info *info)
     = get_elf_backend_data (info->output_bfd);
   unsigned int elfclass = bed->s->elfclass;
   int elf_machine_code = bed->elf_machine_code;
-
-  /* Find the first relocatable ELF input with GNU properties.  */
+  bfd_boolean has_text = FALSE;
+  bfd *elf_bfd = NULL;
+  asection *first_psec = NULL;
+  bfd_boolean need_phdrs = FALSE;
+
+  /* Find the first relocatable ELF input and the first relocatable ELF
+     input with GNU properties.  Ignore GNU properties from ELF objects
+     with different machine code or class.  */
   for (abfd = info->input_bfds; abfd != NULL; abfd = abfd->link.next)
     if (bfd_get_flavour (abfd) == bfd_target_elf_flavour
 	&& (abfd->flags & DYNAMIC) == 0
-	&& elf_properties (abfd) != NULL)
+	&& (elf_machine_code
+	    == get_elf_backend_data (abfd)->elf_machine_code)
+	&& elfclass == get_elf_backend_data (abfd)->s->elfclass)
       {
-	has_properties = TRUE;
-
-	/* Ignore GNU properties from ELF objects with different machine
-	   code or class.  Also skip objects without a GNU_PROPERTY note
-	   section.  */
-	if ((elf_machine_code
-	     == get_elf_backend_data (abfd)->elf_machine_code)
-	    && (elfclass
-		== get_elf_backend_data (abfd)->s->elfclass)
-	    && bfd_get_section_by_name (abfd,
-					NOTE_GNU_PROPERTY_SECTION_NAME) != NULL
-	    )
+	elf_bfd = abfd;
+
+	if (!has_text)
+	  {
+	    /* Check if there is no non-empty text section.  */
+	    sec = bfd_get_section_by_name (abfd, ".text");
+	    if (sec != NULL && sec->size != 0)
+	      has_text = TRUE;
+	  }
+
+	if (elf_properties (abfd) != NULL)
 	  {
-	    /* Keep .note.gnu.property section in FIRST_PBFD.  */
-	    first_pbfd = abfd;
-	    break;
+	    has_properties = TRUE;
+
+	    /* Skip objects without a GNU_PROPERTY note section.  */
+	    sec = bfd_get_section_by_name (abfd,
+					   NOTE_GNU_PROPERTY_SECTION_NAME);
+	    if (sec)
+	      {
+		first_psec = sec;
+		/* Keep .note.gnu.property section in FIRST_PBFD.  */
+		first_pbfd = abfd;
+		break;
+	      }
 	  }
       }
 
-  /* Do nothing if there is no .note.gnu.property section.  */
-  if (!has_properties)
+  /* If the separate code program header is needed, make sure
+     that the first read-only PT_LOAD segment has no code by
+     adding a GNU_PROPERTY_NEED_PHDRS property.  */
+  if (has_text
+      && elf_tdata (info->output_bfd)->o->build_id.sec == NULL
+      && !elf_hash_table (info)->dynamic_sections_created
+      && !info->traditional_format
+      && (info->output_bfd->flags & D_PAGED) != 0
+      && info->separate_code)
+    need_phdrs = TRUE;
+
+  /* Do nothing if there is no .note.gnu.property section and we don't
+     need a GNU_PROPERTY_NEED_PHDRS property.  */
+  if (!has_properties && !need_phdrs)
     return NULL;
 
   /* Merge .note.gnu.property sections.  */
@@ -484,15 +526,52 @@ _bfd_elf_link_setup_gnu_properties (struct bfd_link_info *info)
 
   /* Rewrite .note.gnu.property section so that GNU properties are
      always sorted by type even if input GNU properties aren't sorted.  */
-  if (first_pbfd != NULL)
+  if (first_pbfd != NULL || need_phdrs)
     {
       bfd_size_type size;
       bfd_byte *contents;
       unsigned int align_size = elfclass == ELFCLASS64 ? 8 : 4;
 
-      sec = bfd_get_section_by_name (first_pbfd,
-				     NOTE_GNU_PROPERTY_SECTION_NAME);
-      BFD_ASSERT (sec != NULL);
+      if (need_phdrs)
+	{
+	  elf_property *prop;
+
+	  if (first_pbfd)
+	    sec = first_psec;
+	  else
+	    {
+	      /* Create the GNU property note section if needed.  */
+	      sec = bfd_make_section_with_flags (elf_bfd,
+						 NOTE_GNU_PROPERTY_SECTION_NAME,
+						 (SEC_ALLOC
+						  | SEC_LOAD
+						  | SEC_IN_MEMORY
+						  | SEC_READONLY
+						  | SEC_HAS_CONTENTS
+						  | SEC_DATA));
+	      if (sec == NULL)
+		info->callbacks->einfo (_("%F%P: failed to create GNU property section\n"));
+
+	      if (!bfd_set_section_alignment (elf_bfd, sec,
+					      (elfclass == ELFCLASS64
+					       ? 3 : 2)))
+		info->callbacks->einfo (_("%F%pA: failed to align section\n"),
+					first_psec);
+
+	      elf_section_type (sec) = SHT_NOTE;
+	      first_pbfd = elf_bfd;
+	    }
+
+	  if (elf_properties (first_pbfd) == NULL)
+	    {
+	      prop = _bfd_elf_get_property (first_pbfd,
+					    GNU_PROPERTY_NEED_PHDRS,
+					    0);
+	      prop->pr_kind = property_number;
+	    }
+	}
+      else
+	sec = first_psec;
 
       /* Update stack size in .note.gnu.property with -z stack-size=N
 	 if N > 0.  */
diff --git a/binutils/readelf.c b/binutils/readelf.c
index 91f4c12286..e54f401f0d 100644
--- a/binutils/readelf.c
+++ b/binutils/readelf.c
@@ -17378,6 +17378,12 @@ print_gnu_property_note (Filedata * filedata, Elf_Internal_Note * pnote)
 		printf (_("<corrupt length: %#x> "), datasz);
 	      goto next;
 
+	    case GNU_PROPERTY_NEED_PHDRS:
+	      printf ("need phdrs ");
+	      if (datasz)
+		printf (_("<corrupt length: %#x> "), datasz);
+	      goto next;
+
 	    default:
 	      break;
 	    }
diff --git a/include/elf/common.h b/include/elf/common.h
index e194274305..149dd91e4e 100644
--- a/include/elf/common.h
+++ b/include/elf/common.h
@@ -738,6 +738,7 @@
 /* Values used in GNU .note.gnu.property notes (NT_GNU_PROPERTY_TYPE_0).  */
 #define GNU_PROPERTY_STACK_SIZE			1
 #define GNU_PROPERTY_NO_COPY_ON_PROTECTED	2
+#define GNU_PROPERTY_NEED_PHDRS			3
 
 /* Processor-specific semantics, lo */
 #define GNU_PROPERTY_LOPROC  0xc0000000
-- 
2.17.1


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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00           ` H.J. Lu
@ 2018-01-01  0:00             ` Michael Matz
  2018-01-01  0:00               ` H.J. Lu
  0 siblings, 1 reply; 18+ messages in thread
From: Michael Matz @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Rich Felker, Cary Coutant, Carlos O'Donell, Florian Weimer,
	Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

Hi,

On Tue, 2 Oct 2018, H.J. Lu wrote:

> > > If linker script discards a section, all bets are off.  Anything can 
> > > happen.
> >
> > I disagree, but even if I'd agree your solution still is more 
> > accidental than by design.  You want to guarantee something about 
> > program headers, so any solution that doesn't do anything specific 
> > about/with program headers is similarly accidental.
> 
> Nothing is guaranteed when linker script is used since anything can 
> happen with linker script.

Ignore the parts about the linker script, I disagree with you, but that's 
immaterial to my main point.  Your solution still is only an accidental 
one as you don't do anything about program headers but instead just add 
magic sections to magic places that happens to do what you want currently.  
That's not by design.


Ciao,
Michael.

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00               ` H.J. Lu
@ 2018-01-01  0:00                 ` Cary Coutant
  2018-01-01  0:00                   ` Alan Modra
  0 siblings, 1 reply; 18+ messages in thread
From: Cary Coutant @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Michael Matz, Rich Felker, Carlos O'Donell, Florian Weimer,
	nsz, Jan Beulich, Binutils, gnu-gabi

> 1. Linker kernel passes AT_PHDR to main and assumes that AT_PHDR
> is in a PT_LOAD segment.

s/Linker/Linux/

One could argue that this is the real (and only) problem. If it's
going to pass a pointer to the program headers, the kernel should make
sure that the headers are mapped, whether or not they're part of a
PT_LOAD segment.

Even with no-separate-code, or with a read-only segment before the
text, the inclusion of the program headers in the first PT_LOAD
segment is merely a happy accident -- it's a side effect of way the
linker rounds segment boundaries down and up to page boundaries, and
depends entirely on the property that the first PT_LOAD segment falls
within the first page of the executable file. If, for some reason, the
linker were to place additional non-loadable stuff between the headers
and the text (e.g., symbol tables, section tables), this could fail.
In fact, if the program headers themselves happen to be so large as to
spill over onto the second page of the file, the first PT_LOAD segment
would not necessarily include the first page of the file.

Now, I understand that fixing the Linux kernel to map the headers even
if they're not part of a PT_LOAD segment isn't a practical
alternative. That leads to...

> 2. gABI doesn't require phdrs in a PT_LOAD segment.

It doesn't belong in the gABI, as the mechanics of making the program
header information available to the dynamic loader and the running
program are processor- and OS-specific.

Since this is a Linux-specific issue, not an architecture-specific
one, we really should put this in an osABI document rather than a
psABI document. I suppose the LSB serves as such. Or maybe the gnu ABI
document?

> 3. Ld won't create a PT_LOAD segment just to hold phdrs.

You seem to be breezing right past the idea of doing exactly this.
Why? The scripting language already allows you to declare which
segment should include FILEHDR and PHDRS. For -z separate-code, why
not use a default linker script with something like the following?

     PHDRS
     {
       headers PT_PHDR PHDRS ;
       interp PT_INTERP ;
       header_seg PT_LOAD FILEHDR PHDRS ;
       text PT_LOAD ;
       data PT_LOAD ;
       dynamic PT_DYNAMIC ;
     }

> 4. With -z separate-code, linker won't put any non-code in a PF_X PT_LOAD
> segment.
>
> When there are only PF_X PT_LOAD segments, phdrs isn't in any PT_LOAD
> segment.
>
> You are looking for a solution to create a PT_LOAD segment just to hold phdrs.
> I have investigated it.  It is very intrusive.  My solution, which you
> called a hack,
> is to add a read-only SHF_ALLOC section so that a PT_LOAD segment will
> be created by ld to hold phdrs when there is only PF_X PT_LOAD segments
> otherwise.

How is it intrusive? If the above linker script doesn't do the job,
isn't that a bug anyway?

And, really, there's no denying that adding an otherwise-unnecessary
note section -- just to get us back into the realm of "it works by
happy accident" -- is a pure hack.

-cary

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00                       ` Alan Modra
@ 2018-01-01  0:00                         ` Cary Coutant
  2018-01-01  0:00                           ` H.J. Lu
  0 siblings, 1 reply; 18+ messages in thread
From: Cary Coutant @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Alan Modra
  Cc: H.J. Lu, Michael Matz, Rich Felker, Carlos O'Donell,
	Florian Weimer, nsz, Jan Beulich, Binutils, gnu-gabi

> If you specify PHDRS in a script, ld uses exactly those program
> headers, and I believe it should continue to operate that way.  So to
> add PT_GNU_EH_FRAME, say, when an executable has .eh_frame_hdr, you'd
> need a script with PT_GNU_EH_FRAME specified in PHDRS.  And another
> without PT_GNU_EH_FRAME when the executable doesn't have
> .eh_frame_hdr.  That soon becomes impractial considering the number of
> optional headers, requiring auto-generation of the PHDRS script
> snippet.

Oh, I see. Yeah, that does make it impractical.

Still, I'd like to understand why HJ claims it's intrusive to have ld
create a PT_LOAD segment for the headers. I haven't tried it yet in
gold (don't support -z separate-code), but it doesn't seem like it
would be at all difficult or intrusive.

-cary

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00                         ` Cary Coutant
@ 2018-01-01  0:00                           ` H.J. Lu
  2018-01-01  0:00                             ` Rich Felker
  0 siblings, 1 reply; 18+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Cary Coutant
  Cc: Alan Modra, Michael Matz, Rich Felker, Carlos O'Donell,
	Florian Weimer, Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

On Thu, Oct 4, 2018 at 8:10 AM Cary Coutant <ccoutant@gmail.com> wrote:
>
> > If you specify PHDRS in a script, ld uses exactly those program
> > headers, and I believe it should continue to operate that way.  So to
> > add PT_GNU_EH_FRAME, say, when an executable has .eh_frame_hdr, you'd
> > need a script with PT_GNU_EH_FRAME specified in PHDRS.  And another
> > without PT_GNU_EH_FRAME when the executable doesn't have
> > .eh_frame_hdr.  That soon becomes impractial considering the number of
> > optional headers, requiring auto-generation of the PHDRS script
> > snippet.
>
> Oh, I see. Yeah, that does make it impractical.
>
> Still, I'd like to understand why HJ claims it's intrusive to have ld
> create a PT_LOAD segment for the headers. I haven't tried it yet in
> gold (don't support -z separate-code), but it doesn't seem like it
> would be at all difficult or intrusive.

The linker part is relatively easy.  The problems are with strip and
objcopy.  They aren't prepared to deal with it.

-- 
H.J.

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00                 ` Cary Coutant
@ 2018-01-01  0:00                   ` Alan Modra
  2018-01-01  0:00                     ` Cary Coutant
  0 siblings, 1 reply; 18+ messages in thread
From: Alan Modra @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Cary Coutant
  Cc: H.J. Lu, Michael Matz, Rich Felker, Carlos O'Donell,
	Florian Weimer, nsz, Jan Beulich, Binutils, gnu-gabi

On Tue, Oct 02, 2018 at 02:06:43PM -0700, Cary Coutant wrote:
> Even with no-separate-code, or with a read-only segment before the
> text, the inclusion of the program headers in the first PT_LOAD
> segment is merely a happy accident -- it's a side effect of way the
> linker rounds segment boundaries down and up to page boundaries, and
> depends entirely on the property that the first PT_LOAD segment falls
> within the first page of the executable file.

As Michael would say, it's a hack.  ;-)

> > 3. Ld won't create a PT_LOAD segment just to hold phdrs.
> 
> You seem to be breezing right past the idea of doing exactly this.
> Why? The scripting language already allows you to declare which
> segment should include FILEHDR and PHDRS. For -z separate-code, why
> not use a default linker script with something like the following?
> 
>      PHDRS
>      {
>        headers PT_PHDR PHDRS ;
>        interp PT_INTERP ;
>        header_seg PT_LOAD FILEHDR PHDRS ;
>        text PT_LOAD ;
>        data PT_LOAD ;
>        dynamic PT_DYNAMIC ;
>      }

The script idea is probably not practical in view of all the
variations of headers we'd need.  PT_NOTE, PT_TLS, PT_GNU_EH_FRAME,
PT_GNU_STACK, PT_GNU_RELRO come to mind, some of which depend on
executable contents.

I do agree that ld should be modified to create a PT_LOAD just for
headers when needed, probably keyed off SIZEOF_HEADERS in a script.

> And, really, there's no denying that adding an otherwise-unnecessary
> note section -- just to get us back into the realm of "it works by
> happy accident" -- is a pure hack.

I don't particularly like the note section hack, but I can see why HJ
did it that way.  Adding a note section no doubt avoids objcopy bugs
that would otherwise need to be fixed.

-- 
Alan Modra
Australia Development Lab, IBM

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00                           ` H.J. Lu
@ 2018-01-01  0:00                             ` Rich Felker
  2018-01-01  0:00                               ` H.J. Lu
  0 siblings, 1 reply; 18+ messages in thread
From: Rich Felker @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Cary Coutant, Alan Modra, Michael Matz, Carlos O'Donell,
	Florian Weimer, Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

On Thu, Oct 04, 2018 at 09:33:43AM -0700, H.J. Lu wrote:
> On Thu, Oct 4, 2018 at 8:10 AM Cary Coutant <ccoutant@gmail.com> wrote:
> >
> > > If you specify PHDRS in a script, ld uses exactly those program
> > > headers, and I believe it should continue to operate that way.  So to
> > > add PT_GNU_EH_FRAME, say, when an executable has .eh_frame_hdr, you'd
> > > need a script with PT_GNU_EH_FRAME specified in PHDRS.  And another
> > > without PT_GNU_EH_FRAME when the executable doesn't have
> > > .eh_frame_hdr.  That soon becomes impractial considering the number of
> > > optional headers, requiring auto-generation of the PHDRS script
> > > snippet.
> >
> > Oh, I see. Yeah, that does make it impractical.
> >
> > Still, I'd like to understand why HJ claims it's intrusive to have ld
> > create a PT_LOAD segment for the headers. I haven't tried it yet in
> > gold (don't support -z separate-code), but it doesn't seem like it
> > would be at all difficult or intrusive.
> 
> The linker part is relatively easy.  The problems are with strip and
> objcopy.  They aren't prepared to deal with it.

Can you elaborate on what would go wrong with them? AIUI they can't
remove anything from segments; they can only remove non-loaded
sections. (I found this out the hard way a long time ago trying to get
strip to remove unneeded .eh_frame)

Rich

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00     ` Michael Matz
@ 2018-01-01  0:00       ` H.J. Lu
  2018-01-01  0:00         ` Michael Matz
  0 siblings, 1 reply; 18+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Michael Matz
  Cc: Rich Felker, Cary Coutant, Carlos O'Donell, Florian Weimer,
	Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

On Tue, Oct 2, 2018 at 8:13 AM Michael Matz <matz@suse.de> wrote:
>
> Hi,
>
> On Tue, 2 Oct 2018, H.J. Lu wrote:
>
> > A .note.gnu.property section will lead to a read-only data PT_LOAD segment
> > as the first PT_LOAD segment:
>
> Yes, and it's a hack.  This section isn't necessary, it merely is the
> easiest (?) way you found to force ld to create the PT_LOAD segment you
> want.  What about linker scripts that filter out all .note sections?  You
> _still_ want the phdrs to be mapped in that case.  You basically replace
> the current state (where the phdrs are mapped by accident) with a
> different state that still only works by accident.  It would be better to
> make this work by design not accident.
>

If linker script discards a section, all bets are off.  Anything can happen.

-- 
H.J.

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00                     ` Cary Coutant
@ 2018-01-01  0:00                       ` Alan Modra
  2018-01-01  0:00                         ` Cary Coutant
  0 siblings, 1 reply; 18+ messages in thread
From: Alan Modra @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Cary Coutant
  Cc: H.J. Lu, Michael Matz, Rich Felker, Carlos O'Donell,
	Florian Weimer, nsz, Jan Beulich, Binutils, gnu-gabi

On Wed, Oct 03, 2018 at 04:46:10PM -0700, Cary Coutant wrote:
> > > > 3. Ld won't create a PT_LOAD segment just to hold phdrs.
> > >
> > > You seem to be breezing right past the idea of doing exactly this.
> > > Why? The scripting language already allows you to declare which
> > > segment should include FILEHDR and PHDRS. For -z separate-code, why
> > > not use a default linker script with something like the following?
> > >
> > >      PHDRS
> > >      {
> > >        headers PT_PHDR PHDRS ;
> > >        interp PT_INTERP ;
> > >        header_seg PT_LOAD FILEHDR PHDRS ;
> > >        text PT_LOAD ;
> > >        data PT_LOAD ;
> > >        dynamic PT_DYNAMIC ;
> > >      }
> >
> > The script idea is probably not practical in view of all the
> > variations of headers we'd need.  PT_NOTE, PT_TLS, PT_GNU_EH_FRAME,
> > PT_GNU_STACK, PT_GNU_RELRO come to mind, some of which depend on
> > executable contents.
> 
> I don't understand why you say it's not practical. How does the number
> of variations of individual program header table entries matter?

If you specify PHDRS in a script, ld uses exactly those program
headers, and I believe it should continue to operate that way.  So to
add PT_GNU_EH_FRAME, say, when an executable has .eh_frame_hdr, you'd
need a script with PT_GNU_EH_FRAME specified in PHDRS.  And another
without PT_GNU_EH_FRAME when the executable doesn't have
.eh_frame_hdr.  That soon becomes impractial considering the number of
optional headers, requiring auto-generation of the PHDRS script
snippet.

-- 
Alan Modra
Australia Development Lab, IBM

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00                               ` H.J. Lu
@ 2018-01-01  0:00                                 ` Alan Modra
  0 siblings, 0 replies; 18+ messages in thread
From: Alan Modra @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Rich Felker, Cary Coutant, Michael Matz, Carlos O'Donell,
	Florian Weimer, Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

On Thu, Oct 04, 2018 at 12:12:17PM -0700, H.J. Lu wrote:
> On Thu, Oct 4, 2018 at 10:16 AM Rich Felker <dalias@libc.org> wrote:
> > Can you elaborate on what would go wrong with them? AIUI they can't
> > remove anything from segments; they can only remove non-loaded
> > sections. (I found this out the hard way a long time ago trying to get
> > strip to remove unneeded .eh_frame)
> 
> Sorry.  I don't remember the details.

One difficulty is what to put in p_vaddr and p_paddr of a segment
without sections.  I'm working on a linker/bfd solution that doesn't
require a note section.

-- 
Alan Modra
Australia Development Lab, IBM

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00 RFC: Add GNU_PROPERTY_NEED_PHDRS H.J. Lu
@ 2018-01-01  0:00 ` Michael Matz
  2018-01-01  0:00   ` H.J. Lu
  0 siblings, 1 reply; 18+ messages in thread
From: Michael Matz @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Rich Felker, Cary Coutant, Carlos O'Donell, Florian Weimer,
	Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

Hi,

On Fri, 28 Sep 2018, H.J. Lu wrote:

> >> AT_PHDR to main, which points to the unmmaped address.  We can ask 
> >> for kernel change or make kernel happy.
> >
> > Kernel change does not help because nobody is obligated to use a new 
> > kernel. Binutils would be producing binaries that don't work on 
> > existing kernels (if the note hack were reverted or if similar changes 
> > were added to other archs without a note hack; right now of course 
> > it's working again).
> 
> True.
> 
> >> My current .note.gnu.property patch only works for x86.  We can add
> >>
> >> #define GNU_PROPERTY_PHDRS 3
> >>
> >> so that it can be used for all targets.
> >
> > What would this do?
> 
> These are what I have in mind.

I don't see how the patches fix anything, in particular making sure that 
the phdrs are always mapped.  If your intention is (it would be good if 
you can explain it with words) that they only would be made mapped if this 
new property is set, then I'd disagree.  I think they should always be 
made mapped unconditionally.  There are two ways for this: (a) add a new 
PT_LOAD that covers them, (b) move the phdrs into the ro data segment.  I 
find all approaches that add properties or new section types or anything 
else that needs documentation and definition dubious.


Ciao,
Michael.

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00                             ` Rich Felker
@ 2018-01-01  0:00                               ` H.J. Lu
  2018-01-01  0:00                                 ` Alan Modra
  0 siblings, 1 reply; 18+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Rich Felker
  Cc: Cary Coutant, Alan Modra, Michael Matz, Carlos O'Donell,
	Florian Weimer, Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

On Thu, Oct 4, 2018 at 10:16 AM Rich Felker <dalias@libc.org> wrote:
>
> On Thu, Oct 04, 2018 at 09:33:43AM -0700, H.J. Lu wrote:
> > On Thu, Oct 4, 2018 at 8:10 AM Cary Coutant <ccoutant@gmail.com> wrote:
> > >
> > > > If you specify PHDRS in a script, ld uses exactly those program
> > > > headers, and I believe it should continue to operate that way.  So to
> > > > add PT_GNU_EH_FRAME, say, when an executable has .eh_frame_hdr, you'd
> > > > need a script with PT_GNU_EH_FRAME specified in PHDRS.  And another
> > > > without PT_GNU_EH_FRAME when the executable doesn't have
> > > > .eh_frame_hdr.  That soon becomes impractial considering the number of
> > > > optional headers, requiring auto-generation of the PHDRS script
> > > > snippet.
> > >
> > > Oh, I see. Yeah, that does make it impractical.
> > >
> > > Still, I'd like to understand why HJ claims it's intrusive to have ld
> > > create a PT_LOAD segment for the headers. I haven't tried it yet in
> > > gold (don't support -z separate-code), but it doesn't seem like it
> > > would be at all difficult or intrusive.
> >
> > The linker part is relatively easy.  The problems are with strip and
> > objcopy.  They aren't prepared to deal with it.
>
> Can you elaborate on what would go wrong with them? AIUI they can't
> remove anything from segments; they can only remove non-loaded
> sections. (I found this out the hard way a long time ago trying to get
> strip to remove unneeded .eh_frame)

Sorry.  I don't remember the details.

-- 
H.J.

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00       ` H.J. Lu
@ 2018-01-01  0:00         ` Michael Matz
  2018-01-01  0:00           ` H.J. Lu
  0 siblings, 1 reply; 18+ messages in thread
From: Michael Matz @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Rich Felker, Cary Coutant, Carlos O'Donell, Florian Weimer,
	Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

Hi,

On Tue, 2 Oct 2018, H.J. Lu wrote:

> > Yes, and it's a hack.  This section isn't necessary, it merely is the 
> > easiest (?) way you found to force ld to create the PT_LOAD segment 
> > you want.  What about linker scripts that filter out all .note 
> > sections?  You _still_ want the phdrs to be mapped in that case.  You 
> > basically replace the current state (where the phdrs are mapped by 
> > accident) with a different state that still only works by accident.  
> > It would be better to make this work by design not accident.
> 
> If linker script discards a section, all bets are off.  Anything can 
> happen.

I disagree, but even if I'd agree your solution still is more accidental 
than by design.  You want to guarantee something about program headers, so 
any solution that doesn't do anything specific about/with program headers 
is similarly accidental.


Ciao,
Michael.

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00 ` Michael Matz
@ 2018-01-01  0:00   ` H.J. Lu
  2018-01-01  0:00     ` Michael Matz
  0 siblings, 1 reply; 18+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Michael Matz
  Cc: Rich Felker, Cary Coutant, Carlos O'Donell, Florian Weimer,
	Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

On Tue, Oct 2, 2018 at 7:52 AM Michael Matz <matz@suse.de> wrote:
>
> Hi,
>
> On Fri, 28 Sep 2018, H.J. Lu wrote:
>
> > >> AT_PHDR to main, which points to the unmmaped address.  We can ask
> > >> for kernel change or make kernel happy.
> > >
> > > Kernel change does not help because nobody is obligated to use a new
> > > kernel. Binutils would be producing binaries that don't work on
> > > existing kernels (if the note hack were reverted or if similar changes
> > > were added to other archs without a note hack; right now of course
> > > it's working again).
> >
> > True.
> >
> > >> My current .note.gnu.property patch only works for x86.  We can add
> > >>
> > >> #define GNU_PROPERTY_PHDRS 3
> > >>
> > >> so that it can be used for all targets.
> > >
> > > What would this do?
> >
> > These are what I have in mind.
>
> I don't see how the patches fix anything, in particular making sure that
> the phdrs are always mapped.  If your intention is (it would be good if
> you can explain it with words) that they only would be made mapped if this
> new property is set, then I'd disagree.  I think they should always be
> made mapped unconditionally.  There are two ways for this: (a) add a new
> PT_LOAD that covers them, (b) move the phdrs into the ro data segment.  I
> find all approaches that add properties or new section types or anything
> else that needs documentation and definition dubious.
>

A .note.gnu.property section will lead to a read-only data PT_LOAD segment
as the first PT_LOAD segment:

[hjl@gnu-17 ld]$ readelf -WlS tmpdir/pr23428
There are 16 section headers, starting at offset 0x2ed0:

Section Headers:
  [Nr] Name              Type            Address          Off    Size
 ES Flg Lk Inf Al
  [ 0]                   NULL            0000000000000000 000000
000000 00      0   0  0
  [ 1] .note.gnu.property NOTE            0000000000400158 000158
000030 00   A  0   0  8
  [ 2] .text             PROGBITS        0000000000401000 001000
0000ea 00  AX  0   0 16
  [ 3] .rodata           PROGBITS        0000000000402000 002000
000006 01 AMS  0   0  1
  [ 4] .comment          PROGBITS        0000000000000000 002006
00002d 01  MS  0   0  1
  [ 5] .debug_aranges    PROGBITS        0000000000000000 002040
000060 00      0   0 16
  [ 6] .debug_info       PROGBITS        0000000000000000 0020a0
0002f7 00      0   0  1
  [ 7] .debug_abbrev     PROGBITS        0000000000000000 002397
000137 00      0   0  1
  [ 8] .debug_line       PROGBITS        0000000000000000 0024ce
0001a7 00      0   0  1
  [ 9] .debug_frame      PROGBITS        0000000000000000 002678
000040 00      0   0  8
  [10] .debug_str        PROGBITS        0000000000000000 0026b8
0002a1 01  MS  0   0  1
  [11] .debug_loc        PROGBITS        0000000000000000 002959
000295 00      0   0  1
  [12] .debug_ranges     PROGBITS        0000000000000000 002bee
000020 00      0   0  1
  [13] .symtab           SYMTAB          0000000000000000 002c10
0001e0 18     14  14  8
  [14] .strtab           STRTAB          0000000000000000 002df0
000030 00      0   0  1
  [15] .shstrtab         STRTAB          0000000000000000 002e20
0000ab 00      0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
  L (link order), O (extra OS processing required), G (group), T (TLS),
  C (compressed), x (unknown), o (OS specific), E (exclude),
  l (large), p (processor specific)

Elf file type is EXEC (Executable file)
Entry point 0x4010c0
There are 5 program headers, starting at offset 64

Program Headers:
  Type           Offset   VirtAddr           PhysAddr
FileSiz  MemSiz   Flg Align
  LOAD           0x000000 0x0000000000400000 0x0000000000400000
0x000188 0x000188 R   0x1000
  LOAD           0x001000 0x0000000000401000 0x0000000000401000
0x0000ea 0x0000ea R E 0x1000
  LOAD           0x002000 0x0000000000402000 0x0000000000402000
0x000006 0x000006 R   0x1000
  NOTE           0x000158 0x0000000000400158 0x0000000000400158
0x000030 0x000030 R   0x8
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000
0x000000 0x000000 RWE 0x10

 Section to Segment mapping:
  Segment Sections...
   00     .note.gnu.property
   01     .text
   02     .rodata
   03     .note.gnu.property
   04
[hjl@gnu-17 ld]$


-- 
H.J.

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00   ` H.J. Lu
@ 2018-01-01  0:00     ` Michael Matz
  2018-01-01  0:00       ` H.J. Lu
  0 siblings, 1 reply; 18+ messages in thread
From: Michael Matz @ 2018-01-01  0:00 UTC (permalink / raw)
  To: H.J. Lu
  Cc: Rich Felker, Cary Coutant, Carlos O'Donell, Florian Weimer,
	Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

Hi,

On Tue, 2 Oct 2018, H.J. Lu wrote:

> A .note.gnu.property section will lead to a read-only data PT_LOAD segment
> as the first PT_LOAD segment:

Yes, and it's a hack.  This section isn't necessary, it merely is the 
easiest (?) way you found to force ld to create the PT_LOAD segment you 
want.  What about linker scripts that filter out all .note sections?  You 
_still_ want the phdrs to be mapped in that case.  You basically replace 
the current state (where the phdrs are mapped by accident) with a 
different state that still only works by accident.  It would be better to 
make this work by design not accident.


Ciao,
Michael.
> 
> [hjl@gnu-17 ld]$ readelf -WlS tmpdir/pr23428
> There are 16 section headers, starting at offset 0x2ed0:
> 
> Section Headers:
>   [Nr] Name              Type            Address          Off    Size
>  ES Flg Lk Inf Al
>   [ 0]                   NULL            0000000000000000 000000
> 000000 00      0   0  0
>   [ 1] .note.gnu.property NOTE            0000000000400158 000158
> 000030 00   A  0   0  8
>   [ 2] .text             PROGBITS        0000000000401000 001000
> 0000ea 00  AX  0   0 16
>   [ 3] .rodata           PROGBITS        0000000000402000 002000
> 000006 01 AMS  0   0  1
>   [ 4] .comment          PROGBITS        0000000000000000 002006
> 00002d 01  MS  0   0  1
>   [ 5] .debug_aranges    PROGBITS        0000000000000000 002040
> 000060 00      0   0 16
>   [ 6] .debug_info       PROGBITS        0000000000000000 0020a0
> 0002f7 00      0   0  1
>   [ 7] .debug_abbrev     PROGBITS        0000000000000000 002397
> 000137 00      0   0  1
>   [ 8] .debug_line       PROGBITS        0000000000000000 0024ce
> 0001a7 00      0   0  1
>   [ 9] .debug_frame      PROGBITS        0000000000000000 002678
> 000040 00      0   0  8
>   [10] .debug_str        PROGBITS        0000000000000000 0026b8
> 0002a1 01  MS  0   0  1
>   [11] .debug_loc        PROGBITS        0000000000000000 002959
> 000295 00      0   0  1
>   [12] .debug_ranges     PROGBITS        0000000000000000 002bee
> 000020 00      0   0  1
>   [13] .symtab           SYMTAB          0000000000000000 002c10
> 0001e0 18     14  14  8
>   [14] .strtab           STRTAB          0000000000000000 002df0
> 000030 00      0   0  1
>   [15] .shstrtab         STRTAB          0000000000000000 002e20
> 0000ab 00      0   0  1
> Key to Flags:
>   W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
>   L (link order), O (extra OS processing required), G (group), T (TLS),
>   C (compressed), x (unknown), o (OS specific), E (exclude),
>   l (large), p (processor specific)
> 
> Elf file type is EXEC (Executable file)
> Entry point 0x4010c0
> There are 5 program headers, starting at offset 64
> 
> Program Headers:
>   Type           Offset   VirtAddr           PhysAddr
> FileSiz  MemSiz   Flg Align
>   LOAD           0x000000 0x0000000000400000 0x0000000000400000
> 0x000188 0x000188 R   0x1000
>   LOAD           0x001000 0x0000000000401000 0x0000000000401000
> 0x0000ea 0x0000ea R E 0x1000
>   LOAD           0x002000 0x0000000000402000 0x0000000000402000
> 0x000006 0x000006 R   0x1000
>   NOTE           0x000158 0x0000000000400158 0x0000000000400158
> 0x000030 0x000030 R   0x8
>   GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000
> 0x000000 0x000000 RWE 0x10
> 
>  Section to Segment mapping:
>   Segment Sections...
>    00     .note.gnu.property
>    01     .text
>    02     .rodata
>    03     .note.gnu.property
>    04
> [hjl@gnu-17 ld]$
> 
> 
> 

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00                   ` Alan Modra
@ 2018-01-01  0:00                     ` Cary Coutant
  2018-01-01  0:00                       ` Alan Modra
  0 siblings, 1 reply; 18+ messages in thread
From: Cary Coutant @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Alan Modra
  Cc: H.J. Lu, Michael Matz, Rich Felker, Carlos O'Donell,
	Florian Weimer, nsz, Jan Beulich, Binutils, gnu-gabi

> > > 3. Ld won't create a PT_LOAD segment just to hold phdrs.
> >
> > You seem to be breezing right past the idea of doing exactly this.
> > Why? The scripting language already allows you to declare which
> > segment should include FILEHDR and PHDRS. For -z separate-code, why
> > not use a default linker script with something like the following?
> >
> >      PHDRS
> >      {
> >        headers PT_PHDR PHDRS ;
> >        interp PT_INTERP ;
> >        header_seg PT_LOAD FILEHDR PHDRS ;
> >        text PT_LOAD ;
> >        data PT_LOAD ;
> >        dynamic PT_DYNAMIC ;
> >      }
>
> The script idea is probably not practical in view of all the
> variations of headers we'd need.  PT_NOTE, PT_TLS, PT_GNU_EH_FRAME,
> PT_GNU_STACK, PT_GNU_RELRO come to mind, some of which depend on
> executable contents.

I don't understand why you say it's not practical. How does the number
of variations of individual program header table entries matter?

-cary

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00             ` Michael Matz
@ 2018-01-01  0:00               ` H.J. Lu
  2018-01-01  0:00                 ` Cary Coutant
  0 siblings, 1 reply; 18+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Michael Matz
  Cc: Rich Felker, Cary Coutant, Carlos O'Donell, Florian Weimer,
	Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

On Tue, Oct 2, 2018 at 8:48 AM Michael Matz <matz@suse.de> wrote:
>
> Hi,
>
> On Tue, 2 Oct 2018, H.J. Lu wrote:
>
> > > > If linker script discards a section, all bets are off.  Anything can
> > > > happen.
> > >
> > > I disagree, but even if I'd agree your solution still is more
> > > accidental than by design.  You want to guarantee something about
> > > program headers, so any solution that doesn't do anything specific
> > > about/with program headers is similarly accidental.
> >
> > Nothing is guaranteed when linker script is used since anything can
> > happen with linker script.
>
> Ignore the parts about the linker script, I disagree with you, but that's
> immaterial to my main point.  Your solution still is only an accidental
> one as you don't do anything about program headers but instead just add
> magic sections to magic places that happens to do what you want currently.
> That's not by design.

The problem is

1. Linker kernel passes AT_PHDR to main and assumes that AT_PHDR
is in a PT_LOAD segment.
2. gABI doesn't require phdrs in a PT_LOAD segment.
3. Ld won't create a PT_LOAD segment just to hold phdrs.
4. With -z separate-code, linker won't put any non-code in a PF_X PT_LOAD
segment.

When there are only PF_X PT_LOAD segments, phdrs isn't in any PT_LOAD
segment.

You are looking for a solution to create a PT_LOAD segment just to hold phdrs.
I have investigated it.  It is very intrusive.  My solution, which you
called a hack,
is to add a read-only SHF_ALLOC section so that a PT_LOAD segment will
be created by ld to hold phdrs when there is only PF_X PT_LOAD segments
otherwise.

-- 
H.J.

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

* Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
  2018-01-01  0:00         ` Michael Matz
@ 2018-01-01  0:00           ` H.J. Lu
  2018-01-01  0:00             ` Michael Matz
  0 siblings, 1 reply; 18+ messages in thread
From: H.J. Lu @ 2018-01-01  0:00 UTC (permalink / raw)
  To: Michael Matz
  Cc: Rich Felker, Cary Coutant, Carlos O'Donell, Florian Weimer,
	Szabolcs Nagy, Jan Beulich, Binutils, gnu-gabi

On Tue, Oct 2, 2018 at 8:38 AM Michael Matz <matz@suse.de> wrote:
>
> Hi,
>
> On Tue, 2 Oct 2018, H.J. Lu wrote:
>
> > > Yes, and it's a hack.  This section isn't necessary, it merely is the
> > > easiest (?) way you found to force ld to create the PT_LOAD segment
> > > you want.  What about linker scripts that filter out all .note
> > > sections?  You _still_ want the phdrs to be mapped in that case.  You
> > > basically replace the current state (where the phdrs are mapped by
> > > accident) with a different state that still only works by accident.
> > > It would be better to make this work by design not accident.
> >
> > If linker script discards a section, all bets are off.  Anything can
> > happen.
>
> I disagree, but even if I'd agree your solution still is more accidental
> than by design.  You want to guarantee something about program headers, so
> any solution that doesn't do anything specific about/with program headers
> is similarly accidental.
>

Nothing is guaranteed when linker script is used since anything can happen
with linker script.

-- 
H.J.

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

end of thread, other threads:[~2018-10-05  0:01 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-01  0:00 RFC: Add GNU_PROPERTY_NEED_PHDRS H.J. Lu
2018-01-01  0:00 ` Michael Matz
2018-01-01  0:00   ` H.J. Lu
2018-01-01  0:00     ` Michael Matz
2018-01-01  0:00       ` H.J. Lu
2018-01-01  0:00         ` Michael Matz
2018-01-01  0:00           ` H.J. Lu
2018-01-01  0:00             ` Michael Matz
2018-01-01  0:00               ` H.J. Lu
2018-01-01  0:00                 ` Cary Coutant
2018-01-01  0:00                   ` Alan Modra
2018-01-01  0:00                     ` Cary Coutant
2018-01-01  0:00                       ` Alan Modra
2018-01-01  0:00                         ` Cary Coutant
2018-01-01  0:00                           ` H.J. Lu
2018-01-01  0:00                             ` Rich Felker
2018-01-01  0:00                               ` H.J. Lu
2018-01-01  0:00                                 ` Alan Modra

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