public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* powerpc64 function descriptor woes
@ 2003-07-27  9:06 Alan Modra
  0 siblings, 0 replies; 3+ messages in thread
From: Alan Modra @ 2003-07-27  9:06 UTC (permalink / raw)
  To: binutils; +Cc: Steve Munroe, Peter Bergner, Paul Mackerras

Copy relocs on function descriptors lead to all sorts of fun.
Fortunately, (due to code that eliminates unnecessary copy relocs) this
would only trigger if gcc put a non-local function pointer in a
read-only section, which in itself is a bug.

I've also cleaned up H.J.'s new special section table, removing some
entries that are ppc32 only.  Also, since I've tried to keep ld support
code separate from other stuff in elf64-ppc.c, this table belongs in the
"other stuff" area.

bfd/ChangeLog
	* elf64-ppc.c (ppc64_elf_adjust_dynamic_symbol): Ensure no copy relocs
	on function descriptors.
	(ELIMINATE_COPY_RELOCS): Expand comment.
	(ppc64_elf_special_sections): Move.  Don't include non-ppc64 sections.
	Do include ".toc1".

Index: bfd/elf64-ppc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf64-ppc.c,v
retrieving revision 1.120
diff -u -p -r1.120 elf64-ppc.c
--- bfd/elf64-ppc.c	25 Jul 2003 14:35:56 -0000	1.120
+++ bfd/elf64-ppc.c	27 Jul 2003 09:02:23 -0000
@@ -2402,6 +2402,26 @@ ppc64_elf_merge_private_bfd_data (bfd *i
   return TRUE;
 }
 
+/* Add extra PPC sections.  */
+
+static struct bfd_elf_special_section const ppc64_elf_special_sections[]=
+{
+  { ".sdata",		0,	NULL,	0,
+    SHT_PROGBITS,	SHF_ALLOC + SHF_WRITE },
+  { ".sbss",		0,	NULL,	0,
+    SHT_NOBITS,		SHF_ALLOC + SHF_WRITE },
+  { ".plt",		0,	NULL,	0,
+    SHT_NOBITS,		0 },
+  { ".toc",		0,	NULL,	0,
+    SHT_PROGBITS,	SHF_ALLOC + SHF_WRITE },
+  { ".toc1",		0,	NULL,	0,
+    SHT_PROGBITS,	SHF_ALLOC + SHF_WRITE },
+  { ".tocbss",		0,	NULL,	0,
+    SHT_NOBITS,		SHF_ALLOC + SHF_WRITE },
+  { NULL,		0,	NULL,	0,
+    0,			0 }
+};
+
 struct _ppc64_elf_section_data
 {
   struct bfd_elf_section_data elf;
@@ -2580,7 +2600,18 @@ struct plt_entry
 /* If ELIMINATE_COPY_RELOCS is non-zero, the linker will try to avoid
    copying dynamic variables from a shared lib into an app's dynbss
    section, and instead use a dynamic relocation to point into the
-   shared lib.  */
+   shared lib.  With code that gcc generates, it's vital that this be
+   enabled;  In the PowerPC64 ABI, the address of a function is actually
+   the address of a function descriptor, which resides in the .opd
+   section.  gcc uses the descriptor directly rather than going via the
+   GOT as some other ABI's do, which means that initialized function
+   pointers must reference the descriptor.  Thus, a function pointer
+   initialized to the address of a function in a shared library will
+   either require a copy reloc, or a dynamic reloc.  Using a copy reloc
+   redefines the function desctriptor symbol to point to the copy.  This
+   presents a problem as a plt entry for that function is also
+   initialized from the function descriptor symbol and the copy reloc
+   may not be initialized first.  */
 #define ELIMINATE_COPY_RELOCS 1
 
 /* Section name for stubs is the associated section name plus this
@@ -4500,9 +4531,6 @@ ppc64_elf_adjust_dynamic_symbol (struct 
       return TRUE;
     }
 
-  /* This is a reference to a symbol defined by a dynamic object which
-     is not a function.  */
-
   /* If we are creating a shared library, we must presume that the
      only references to the symbol are via the global offset table.
      For such cases we need not do anything here; the relocations will
@@ -4537,6 +4565,12 @@ ppc64_elf_adjust_dynamic_symbol (struct 
 	}
     }
 
+  if (h->plt.plist != NULL)
+    return TRUE;
+
+  /* This is a reference to a symbol defined by a dynamic object which
+     is not a function.  */
+
   /* We must allocate the symbol in our .dynbss section, which will
      become part of the .bss section of the executable.  There will be
      an entry for this symbol in the .dynsym section.  The dynamic
@@ -8761,38 +8795,5 @@ ppc64_elf_finish_dynamic_sections (bfd *
 
   return TRUE;
 }
-
-/* Add extra PPC sections -- Note, for now, make .sbss2 and
-   .PPC.EMB.sbss0 a normal section, and not a bss section so
-   that the linker doesn't crater when trying to make more than
-   2 sections.  */
-
-static struct bfd_elf_special_section const ppc64_elf_special_sections[]=
-{
-  { ".tags",		0,	NULL,	0,
-    SHT_ORDERED,	SHF_ALLOC },
-  { ".sdata",		0,	NULL,	0,
-    SHT_PROGBITS,	SHF_ALLOC + SHF_WRITE },
-  { ".sbss",		0,	NULL,	0,
-    SHT_NOBITS,		SHF_ALLOC + SHF_WRITE },
-  { ".sdata2",		0,	NULL,	0,
-    SHT_PROGBITS,	SHF_ALLOC },
-  { ".sbss2",		0,	NULL,	0,
-    SHT_PROGBITS,	SHF_ALLOC },
-  { ".PPC.EMB.apuinfo",	0,	NULL,	0,
-    SHT_NOTE,		0 },
-  { ".PPC.EMB.sdata0",	0,	NULL,	0,
-    SHT_PROGBITS,	SHF_ALLOC },
-  { ".PPC.EMB.sbss0",	0,	NULL,	0,
-    SHT_PROGBITS,	SHF_ALLOC },
-  { ".plt",		0,	NULL,	0,
-    SHT_NOBITS,		0 },
-  { ".toc",		0,	NULL,	0,
-    SHT_PROGBITS,	SHF_ALLOC + SHF_WRITE },
-  { ".tocbss",		0,	NULL,	0,
-    SHT_NOBITS,		SHF_ALLOC + SHF_WRITE },
-  { NULL,		0,	NULL,	0,
-    0,			0 }
-};
 
 #include "elf64-target.h"

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

* Re: powerpc64 function descriptor woes
  2003-07-28 14:56 Steve Munroe
@ 2003-07-28 15:27 ` Alan Modra
  0 siblings, 0 replies; 3+ messages in thread
From: Alan Modra @ 2003-07-28 15:27 UTC (permalink / raw)
  To: Steve Munroe; +Cc: Peter Bergner, binutils, Paul Mackerras

On Mon, Jul 28, 2003 at 09:55:54AM -0500, Steve Munroe wrote:
> Does this mean that PPC64 gcc/binutils is working again and with GFI?

Toolchain works for me.  Note that older gcc-3.2+patchset based
compilers may now trigger linker errors with mainline binutils.  There
didn't seem to be any easy way to ensure that initialized function
pointer vars copied into main app were all initialized before plt
entries, so I figured a linker error was better than a runtime crash.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

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

* Re: powerpc64 function descriptor woes
@ 2003-07-28 14:56 Steve Munroe
  2003-07-28 15:27 ` Alan Modra
  0 siblings, 1 reply; 3+ messages in thread
From: Steve Munroe @ 2003-07-28 14:56 UTC (permalink / raw)
  To: Alan Modra; +Cc: Peter Bergner, binutils, Paul Mackerras

Does this mean that PPC64 gcc/binutils is working again and with GFI?
 




Alan Modra <amodra@bigpond.net.au>
07/27/2003 04:06 AM

 
        To:     binutils@sources.redhat.com
        cc:     Steve Munroe/Rochester/IBM@IBMUS, Peter Bergner <bergner@vnet.ibm.com>, 
Paul Mackerras <paulus@au1.ibm.com>
        Subject:        powerpc64 function descriptor woes



Copy relocs on function descriptors lead to all sorts of fun.
Fortunately, (due to code that eliminates unnecessary copy relocs) this
would only trigger if gcc put a non-local function pointer in a
read-only section, which in itself is a bug.

I've also cleaned up H.J.'s new special section table, removing some
entries that are ppc32 only.  Also, since I've tried to keep ld support
code separate from other stuff in elf64-ppc.c, this table belongs in the
"other stuff" area.

bfd/ChangeLog
                 * elf64-ppc.c (ppc64_elf_adjust_dynamic_symbol): Ensure 
no copy relocs
                 on function descriptors.
                 (ELIMINATE_COPY_RELOCS): Expand comment.
                 (ppc64_elf_special_sections): Move.  Don't include 
non-ppc64 sections.
                 Do include ".toc1".

Index: bfd/elf64-ppc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf64-ppc.c,v
retrieving revision 1.120
diff -u -p -r1.120 elf64-ppc.c
--- bfd/elf64-ppc.c              25 Jul 2003 14:35:56 -0000 1.120
+++ bfd/elf64-ppc.c              27 Jul 2003 09:02:23 -0000
@@ -2402,6 +2402,26 @@ ppc64_elf_merge_private_bfd_data (bfd *i
   return TRUE;
 }
 
+/* Add extra PPC sections.  */
+
+static struct bfd_elf_special_section const ppc64_elf_special_sections[]=
+{
+  { ".sdata",                           0,              NULL, 0,
+    SHT_PROGBITS,               SHF_ALLOC + SHF_WRITE },
+  { ".sbss",                            0,              NULL, 0,
+    SHT_NOBITS,                                 SHF_ALLOC + SHF_WRITE },
+  { ".plt",                             0,              NULL, 0,
+    SHT_NOBITS,                                 0 },
+  { ".toc",                             0,              NULL, 0,
+    SHT_PROGBITS,               SHF_ALLOC + SHF_WRITE },
+  { ".toc1",                            0,              NULL, 0,
+    SHT_PROGBITS,               SHF_ALLOC + SHF_WRITE },
+  { ".tocbss",                          0,              NULL, 0,
+    SHT_NOBITS,                                 SHF_ALLOC + SHF_WRITE },
+  { NULL,                               0,              NULL, 0,
+    0,                                          0 }
+};
+
 struct _ppc64_elf_section_data
 {
   struct bfd_elf_section_data elf;
@@ -2580,7 +2600,18 @@ struct plt_entry
 /* If ELIMINATE_COPY_RELOCS is non-zero, the linker will try to avoid
    copying dynamic variables from a shared lib into an app's dynbss
    section, and instead use a dynamic relocation to point into the
-   shared lib.  */
+   shared lib.  With code that gcc generates, it's vital that this be
+   enabled;  In the PowerPC64 ABI, the address of a function is actually
+   the address of a function descriptor, which resides in the .opd
+   section.  gcc uses the descriptor directly rather than going via the
+   GOT as some other ABI's do, which means that initialized function
+   pointers must reference the descriptor.  Thus, a function pointer
+   initialized to the address of a function in a shared library will
+   either require a copy reloc, or a dynamic reloc.  Using a copy reloc
+   redefines the function desctriptor symbol to point to the copy.  This
+   presents a problem as a plt entry for that function is also
+   initialized from the function descriptor symbol and the copy reloc
+   may not be initialized first.  */
 #define ELIMINATE_COPY_RELOCS 1
 
 /* Section name for stubs is the associated section name plus this
@@ -4500,9 +4531,6 @@ ppc64_elf_adjust_dynamic_symbol (struct 
       return TRUE;
     }
 
-  /* This is a reference to a symbol defined by a dynamic object which
-     is not a function.  */
-
   /* If we are creating a shared library, we must presume that the
      only references to the symbol are via the global offset table.
      For such cases we need not do anything here; the relocations will
@@ -4537,6 +4565,12 @@ ppc64_elf_adjust_dynamic_symbol (struct 
                 }
     }
 
+  if (h->plt.plist != NULL)
+    return TRUE;
+
+  /* This is a reference to a symbol defined by a dynamic object which
+     is not a function.  */
+
   /* We must allocate the symbol in our .dynbss section, which will
      become part of the .bss section of the executable.  There will be
      an entry for this symbol in the .dynsym section.  The dynamic
@@ -8761,38 +8795,5 @@ ppc64_elf_finish_dynamic_sections (bfd *
 
   return TRUE;
 }
-
-/* Add extra PPC sections -- Note, for now, make .sbss2 and
-   .PPC.EMB.sbss0 a normal section, and not a bss section so
-   that the linker doesn't crater when trying to make more than
-   2 sections.  */
-
-static struct bfd_elf_special_section const ppc64_elf_special_sections[]=
-{
-  { ".tags",                            0,              NULL, 0,
-    SHT_ORDERED,                SHF_ALLOC },
-  { ".sdata",                           0,              NULL, 0,
-    SHT_PROGBITS,               SHF_ALLOC + SHF_WRITE },
-  { ".sbss",                            0,              NULL, 0,
-    SHT_NOBITS,                                 SHF_ALLOC + SHF_WRITE },
-  { ".sdata2",                          0,              NULL, 0,
-    SHT_PROGBITS,               SHF_ALLOC },
-  { ".sbss2",                           0,              NULL, 0,
-    SHT_PROGBITS,               SHF_ALLOC },
-  { ".PPC.EMB.apuinfo",                 0,              NULL, 0,
-    SHT_NOTE,                           0 },
-  { ".PPC.EMB.sdata0",          0,              NULL,           0,
-    SHT_PROGBITS,               SHF_ALLOC },
-  { ".PPC.EMB.sbss0",           0,              NULL,           0,
-    SHT_PROGBITS,               SHF_ALLOC },
-  { ".plt",                             0,              NULL, 0,
-    SHT_NOBITS,                                 0 },
-  { ".toc",                             0,              NULL, 0,
-    SHT_PROGBITS,               SHF_ALLOC + SHF_WRITE },
-  { ".tocbss",                          0,              NULL, 0,
-    SHT_NOBITS,                                 SHF_ALLOC + SHF_WRITE },
-  { NULL,                               0,              NULL, 0,
-    0,                                          0 }
-};
 
 #include "elf64-target.h"

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre



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

end of thread, other threads:[~2003-07-28 15:27 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-27  9:06 powerpc64 function descriptor woes Alan Modra
2003-07-28 14:56 Steve Munroe
2003-07-28 15:27 ` 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).