This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
PowerPC64 toc edit fail
- From: Alan Modra <amodra at gmail dot com>
- To: binutils at sourceware dot org
- Date: Fri, 19 Aug 2011 17:36:40 +0930
- Subject: 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