This is the mail archive of the 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]
Other format: [Raw text]

PowerPC64 toc edit fail

When looking over .toc entries for ones from gcc's -mcmodel=medium or
-mcmodel=large code that can be deleted when ld optimizes the code, ld
first marked the entries with a flag then later reset the flag if
-mcmodel=small code accesses were found.  The trouble with this is the
flag remains set if no code in the current file accesses the toc
entry.  Then the entry is deleted.  That fails when the toc is
accessed from another file using global symbols on the toc entries,
something that ld doesn't consider when optimizing the toc.  Now, gcc
never generates code that accesses the toc in another object, but
IBM's xlf does, and there's no reason why xlf or user code shouldn't
do that;  ld toc editing is supposed to be conservative.

The following patch ensures that the flag is cleared if ld never sees
any access to the toc entry in the current file.  It's not completely
foolproof, but should be enough to cure the xlf problem.

	* elf64-ppc.c (ppc64_elf_edit_toc): Ignore can_optimize bit if
	we haven't seen expected -mcmodel=medium/large code relocs.

Index: bfd/elf64-ppc.c
RCS file: /cvs/src/src/bfd/elf64-ppc.c,v
retrieving revision 1.360
diff -u -p -r1.360 elf64-ppc.c
--- bfd/elf64-ppc.c	14 Aug 2011 08:11:56 -0000	1.360
+++ bfd/elf64-ppc.c	19 Aug 2011 02:13:57 -0000
@@ -8267,7 +8362,7 @@ ppc64_elf_edit_toc (struct bfd_link_info
 		some_unused = 1;
 	      last = 0;
-	  else if (*drop)
+	  else if (*drop & ref_from_discarded)
 	      some_unused = 1;
 	      last = ref_from_discarded;

Alan Modra
Australia Development Lab, IBM

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