Accept odd result in ld-powerpc/tocnovar testcase

Accept odd result in ld-powerpc/tocnovar testcase

[Alan Modra]

I didn't commit this with the relro and powerpc .TOC. changes,
thinking that something should be done about the odd result of
.shstrtab appearing in PT_GNU_RELRO.  On looking at it further,
I think that changing readelf would be wrong, so let's just
accept the results.  Real binaries will always have other sections
past .got, so PT_GNU_RELRO won't finish past the end of loaded
sections.

  [ 1] .text     PROGBITS 100000e8 0000e8 000008 00  AX  0   0  8
  [ 2] .eh_frame PROGBITS 100000f0 0000f0 000000 00   A  0   0  4
  [ 3] .opd      PROGBITS 1001fee8 00fee8 000018 00  WA  0   0  8
  [ 4] .got      PROGBITS 1001ff00 00ff00 000004 00  WA  0   0 256
  [ 5] .shstrtab STRTAB   00000000 00ff04 000035 00      0   0  1
  [ 6] .symtab   SYMTAB   00000000 00ff40 000108 18      7   7  8
  [ 7] .strtab   STRTAB   00000000 010048 000034 00      0   0  1

  LOAD      0x000000 0x10000000 0x10000000 0x0000f0 0x0000f0 R E 0x10000
  LOAD      0x00fee8 0x1001fee8 0x1001fee8 0x00001c 0x00001c RW  0x10000
  GNU_RELRO 0x00fee8 0x1001fee8 0x1001fee8 0x000118 0x000118 R   0x1

  Segment Sections...
   00     .text 
   01     .opd .got 
   02     .opd .got .shstrtab 

	* ld-powerpc/tocnovar.d: Adjust.

diff --git a/ld/testsuite/ld-powerpc/tocnovar.d b/ld/testsuite/ld-powerpc/tocnovar.d
index d1fd258..475617a 100644
--- a/ld/testsuite/ld-powerpc/tocnovar.d
+++ b/ld/testsuite/ld-powerpc/tocnovar.d
@@ -11,4 +11,4 @@
 #...
  +00 +\.text 
  +01 +\.opd \.got 
- +02 +\.opd \.got 
+ +02 +\.opd \.got .*

-- 
Alan Modra
Australia Development Lab, IBM

Re: Accept odd result in ld-powerpc/tocnovar testcase

[Cary Coutant]

> I didn't commit this with the relro and powerpc .TOC. changes,
> thinking that something should be done about the odd result of
> .shstrtab appearing in PT_GNU_RELRO.  On looking at it further,
> I think that changing readelf would be wrong, so let's just
> accept the results.  Real binaries will always have other sections
> past .got, so PT_GNU_RELRO won't finish past the end of loaded
> sections.

Still, why should readelf show any non-allocated sections as part of a segment?

-cary

Re: Accept odd result in ld-powerpc/tocnovar testcase

[Alan Modra]

On Thu, Apr 23, 2015 at 08:06:17AM -0700, Cary Coutant wrote:
> > I didn't commit this with the relro and powerpc .TOC. changes,
> > thinking that something should be done about the odd result of
> > .shstrtab appearing in PT_GNU_RELRO.  On looking at it further,
> > I think that changing readelf would be wrong, so let's just
> > accept the results.  Real binaries will always have other sections
> > past .got, so PT_GNU_RELRO won't finish past the end of loaded
> > sections.
> 
> Still, why should readelf show any non-allocated sections as part of a segment?

I shouldn't have said "would be wrong" without qualifying.  The truth
is more like: Changing readelf to not show the non-alloc sections
involves changing include/elf/internal.h ELF_SECTION_IN_SEGMENT_1.  My
first attempt resulted in failures of ld-elf/maxpage5, ld-elf/note-1
and ld-elf/note-2.  At that point I decided I didn't want to spend
time on the problem, and it would be wrong to make a change there
without significant research.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Accept odd result in ld-powerpc/tocnovar testcase

[Alan Modra]

On Fri, Apr 24, 2015 at 11:56:48AM +0930, Alan Modra wrote:
> On Thu, Apr 23, 2015 at 08:06:17AM -0700, Cary Coutant wrote:
> > > I didn't commit this with the relro and powerpc .TOC. changes,
> > > thinking that something should be done about the odd result of
> > > .shstrtab appearing in PT_GNU_RELRO.  On looking at it further,
> > > I think that changing readelf would be wrong, so let's just
> > > accept the results.  Real binaries will always have other sections
> > > past .got, so PT_GNU_RELRO won't finish past the end of loaded
> > > sections.
> > 
> > Still, why should readelf show any non-allocated sections as part of a segment?
> 
> I shouldn't have said "would be wrong" without qualifying.  The truth
> is more like: Changing readelf to not show the non-alloc sections
> involves changing include/elf/internal.h ELF_SECTION_IN_SEGMENT_1.  My
> first attempt resulted in failures of ld-elf/maxpage5, ld-elf/note-1
> and ld-elf/note-2.  At that point I decided I didn't want to spend
> time on the problem, and it would be wrong to make a change there
> without significant research.

Curiousity killed the cat.  I got hooked.

Non-alloc sections don't belong in PT_LOAD segments

Taking them out showed a bug in the powerpc64 backend with .branch_lt
being removed from output_bfd but not from previously set up segment
section maps.  Removing the bfd sections meant their sh_flags (and
practically everything else) remaining zero, ie. not SHF_ALLOC,
triggering complaints about "`.branch_lt' can't be allocated in
segment".

include/elf/
	* internal.h (ELF_SECTION_IN_SEGMENT_1): Ensure PT_LOAD and
	similar segments only contain alloc sections.
ld/
	* emultempl/ppc64elf.em (gld${EMULATION_NAME}_after_allocation):
	Call gld${EMULATION_NAME}_map_segments regardless of need_laying_out.
ld/testsuite/
	* ld-powerpc/tocnovar.d: Revert last change.

diff --git a/include/elf/internal.h b/include/elf/internal.h
index b2492f5..b49dd61 100644
--- a/include/elf/internal.h
+++ b/include/elf/internal.h
@@ -325,6 +325,13 @@ struct elf_segment_map
     || (((sec_hdr)->sh_flags & SHF_TLS) == 0				\
 	&& (segment)->p_type != PT_TLS					\
 	&& (segment)->p_type != PT_PHDR))				\
+   /* PT_LOAD and similar segments only have SHF_ALLOC sections.  */	\
+   && !(((sec_hdr)->sh_flags & SHF_ALLOC) == 0				\
+	&& ((segment)->p_type == PT_LOAD				\
+	    || (segment)->p_type == PT_DYNAMIC				\
+	    || (segment)->p_type == PT_GNU_EH_FRAME			\
+	    || (segment)->p_type == PT_GNU_RELRO			\
+	    || (segment)->p_type == PT_GNU_STACK))			\
    /* Any section besides one of type SHT_NOBITS must have file		\
       offsets within the segment.  */					\
    && ((sec_hdr)->sh_type == SHT_NOBITS					\
diff --git a/ld/emultempl/ppc64elf.em b/ld/emultempl/ppc64elf.em
index fd9a3ce..2d26a95 100644
--- a/ld/emultempl/ppc64elf.em
+++ b/ld/emultempl/ppc64elf.em
@@ -546,13 +546,16 @@ gld${EMULATION_NAME}_after_allocation (void)
   else if (ret > 0)
     need_laying_out = 1;
 
-  if (need_laying_out != -1)
-    {
-      gld${EMULATION_NAME}_map_segments (need_laying_out);
-
-      if (!link_info.relocatable)
-	ppc64_elf_set_toc (&link_info, link_info.output_bfd);
-    }
+  /* Call map_segments regardless of the state of need_laying_out.
+     need_laying_out set to -1 means we have just laid everything out,
+     but ppc64_elf_size_stubs strips .branch_lt and .eh_frame if
+     unneeded, after ppc_layout_sections_again.  Another call removes
+     these sections from the segment map.  Their presence is
+     innocuous except for confusing ELF_SECTION_IN_SEGMENT.  */
+  gld${EMULATION_NAME}_map_segments (need_laying_out > 0);
+
+  if (need_laying_out != -1 && !link_info.relocatable)
+    ppc64_elf_set_toc (&link_info, link_info.output_bfd);
 }
 
 
diff --git a/ld/testsuite/ld-powerpc/tocnovar.d b/ld/testsuite/ld-powerpc/tocnovar.d
index 475617a..d1fd258 100644
--- a/ld/testsuite/ld-powerpc/tocnovar.d
+++ b/ld/testsuite/ld-powerpc/tocnovar.d
@@ -11,4 +11,4 @@
 #...
  +00 +\.text 
  +01 +\.opd \.got 
- +02 +\.opd \.got .*
+ +02 +\.opd \.got

-- 
Alan Modra
Australia Development Lab, IBM