This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: Fix linkonce for ELF/PPC.


OK, I've spent some time debugging this problem.

Looking at .rela.eh_frame in the bad libstdc++, I see a bunch of
RELATIVE relocs, none of which should cause problems, ADDR32 relocs
against __gxx_personality_v0, again no problem, and some NONE relocs.
These are the infamous relocs against removed linkonce sections.

>From a little investigation under gdb, it appears that they were
originally all ADDR32 relocs (with something like HJ's patch of
http://sources.redhat.com/ml/binutils/2001-10/msg00589.html applied,
they are massaged to RELATIVE relocs before being written, see
elf32-ppc.c:3244).  Now the problem with turning these relocs into
R_PPC_NONE, as the current code does, is that ppc gas puts the addend
into the section contents as well as the reloc.  Furthermore,
gcc-3.0.x eh_frame data has relocations against local syms in linkonce
sections.  That means the section contents for things like a fde
pc_begin might be left non-zero.  Thus code in gcc/unwind-dw2-fde.c
that tries to discard these bogus fdes won't work.

One curious fact about turning the reloc into a RELATIVE reloc is that
if the reloc is copied to the shared lib the final value won't be
zero unless the shared lib loads at zero.  So, I'm not sure why HJ's
patch works at all.

I'm leaning towards the following fix, which ensures that any
relocation against a removed linkonce section sym resolves to zero,
regardless of addend.  Seems to cure the ppc problem.  Not tested
terribly well yet, and needs similar changes in other back-ends to
code that copies relocs into shared libs.  The reason I'm posting this
now is a) the above explanation for what is wrong may prompt a better
fix from someone, b) I'm not dead certain that trimming off STN_UNDEF
relocs is always correct.  ie. There may be some reason for them to
appear in input sections during a shared link.  Anyone like to comment
on this?

-- 
Alan Modra

	* elflink.h (elf_link_input_bfd <removed linkonce relocs>): Don't
	zero entire reloc, just zero the addend and sym.
	* elf32-ppc.c (ppc_elf_relocate_section): Don't copy STN_UNDEF
	relocs into shared libs.

Index: bfd/elf32-ppc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-ppc.c,v
retrieving revision 1.34
diff -u -p -r1.34 elf32-ppc.c
--- elf32-ppc.c	2001/10/19 02:11:04	1.34
+++ elf32-ppc.c	2001/11/06 13:11:00
@@ -3175,7 +3175,7 @@ ppc_elf_relocate_section (output_bfd, in
 	case (int) R_PPC_ADDR14:
 	case (int) R_PPC_UADDR32:
 	case (int) R_PPC_UADDR16:
-	  if (info->shared)
+	  if (info->shared && r_symndx != 0)
 	    {
 	      Elf_Internal_Rela outrel;
 	      boolean skip;
Index: bfd/elflink.h
===================================================================
RCS file: /cvs/src/src/bfd/elflink.h,v
retrieving revision 1.119
diff -u -p -r1.119 elflink.h
--- elflink.h	2001/10/31 16:42:48	1.119
+++ elflink.h	2001/11/06 13:11:08
@@ -6152,7 +6152,9 @@ elf_link_input_bfd (finfo, input_bfd)
 			       _("warning: relocation against removed section; zeroing"),
 			       NULL, input_bfd, o, rel->r_offset);
 #endif
-			    memset (rel, 0, sizeof (*rel));
+			    rel->r_info
+			      = ELF_R_INFO (0, ELF_R_TYPE (rel->r_info));
+			    rel->r_addend = 0;
 			  }
 		      }
 		  }


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]