Bug 855163

Summary: internal error, aborting at ../../bfd/elf64-ppc.c line 10584 in ppc64_elf_relocate_section
Product: Red Hat Enterprise Linux 5 Reporter: Petr Machata <pmachata>
Component: binutilsAssignee: Jeff Law <law>
Status: CLOSED ERRATA QA Contact: Martin Cermak <mcermak>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.8CC: jhorak, law, mcermak, mfranc, mnewsome, ohudlick, stransky
Target Milestone: rc   
Target Release: ---   
Hardware: ppc64   
OS: Unspecified   
Whiteboard:
Fixed In Version: binutils-2.17.50.0.6-24.el5 Doc Type: Bug Fix
Doc Text:
Cause: The PowerPC linker made assumptions about the order of instructions/relocations. Those assumptions are not true for code compiled with gcc-4.1. Consequence: As a result the linker could trip an internal error during optimization of TLS sequences Fix: The linker code to optimize TLS has been modified to not try and optimize TLS sequences which do not meet its assumptions about code & relocation ordering. Result: The linker no longer triggers an internal error when optimizing TLS sequences.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-30 22:11:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 921048, 928849    
Attachments:
Description Flags
Diff between -O1 and -O2 object files
none
Patch for ppc32 instance. Doesn't apply 100% cleanly, but can be fixed up by hand
none
Patch for ppc32 instance. Doesn't apply 100% cleanly, but can be fixed up by hand
none
Patch for ppc64 instance. Doesn't apply 100% cleanly, but can be fixed up by hand none

Description Petr Machata 2012-09-06 20:45:37 UTC
Created attachment 610497 [details]
Diff between -O1 and -O2 object files

The following is the minimal-est reproducer that I could craft:

static __thread int global_error;
const char *brblanina (int error) {
  if (error == 0) return global_error != 0 ? "" : 0;
  return "";
}

$ gcc -fpic -O2 -m64 -mminimal-toc -c ble.c -o ble-pic-minimal-toc-O2.o
$ gcc -m64 ble-pic-minimal-toc-O2.o
/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../../lib64/crt1.o:(.data.rel.ro.local+0x8): undefined reference to `main'
/usr/bin/ld: BFD 2.17.50.0.6-20.el5 20061020 internal error, aborting at ../../bfd/elf64-ppc.c line 10584 in ppc64_elf_relocate_section

/usr/bin/ld: Please report this bug.

collect2: ld returned 1 exit status

Removing any of -mminimal-toc, -fpic, or -O2 leads to success.  It's especially bewildering for -O1 vs. -O2, where the latter fails, but the object files are practically the same (diff attached).

Version-Release number of selected component (if applicable):
# rpm -q binutils gcc
binutils-2.17.50.0.6-20.el5
gcc-4.1.2-52.el5

Comment 1 Petr Machata 2012-09-06 20:46:19 UTC
Forgot to mention that it happens on ppc64.

Comment 2 Jeff Law 2012-09-07 04:30:40 UTC
It's a problem in the TLS optimizations.  With some work it can be triggered on ppc32 as well.

Comment 3 Jeff Law 2012-09-07 04:32:53 UTC
Created attachment 610607 [details]
Patch for ppc32 instance.   Doesn't apply 100% cleanly, but can be fixed up by hand

Comment 4 Jeff Law 2012-09-07 04:34:09 UTC
Created attachment 610608 [details]
Patch for ppc32 instance.   Doesn't apply 100% cleanly, but can be fixed up by hand

Comment 5 Jeff Law 2012-09-07 04:37:46 UTC
Created attachment 610611 [details]
Patch for ppc64 instance.   Doesn't apply 100% cleanly, but can be fixed up by hand

Comment 6 Jan Horak 2012-11-01 07:24:06 UTC
Same problem with upcoming Firefox ESR rebase here: https://brewweb.devel.redhat.com/taskinfo?taskID=5034564

Comment 7 Martin Stransky 2012-11-06 09:20:29 UTC
Hi, 

any update here? This bug blocks upcomming Firefox 17 security rebase. Is there any workaround available?

Thanks!

Comment 8 Jan Horak 2012-11-07 10:23:54 UTC
We can't use -mminimal-toc or -fpic. Without -mminimal-toc build ends with:

/usr/bin/ld: ../../layout/generic/nsFrame.o(.text._ZNK8nsIFrame23GetScreenRectInAppUnitsEv+0x134): sibling call optimization to `NS_round(double)' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `NS_round(double)' extern
See: https://brewweb.devel.redhat.com/taskinfo?taskID=5057432

The -fno-optimize-sibling-calls also didn't help.

I will try build with -O1 but we don't want to slow down firefox by less optimization.

Comment 9 Petr Machata 2012-11-07 11:51:35 UTC
(In reply to comment #8)
> I will try build with -O1 but we don't want to slow down firefox by less
> optimization.

I don't know how the build system of Firefox looks, but it should be possible to patch flags of the offending files only.  I'd try to build with make -k to see if there are many more impacted object files.

Comment 10 Jeff Law 2012-11-29 20:17:40 UTC
Jan/Martin,

Sorry, I didn't see your comments from earlier this month.

You might look and see if there's any way to turn off the linker optimizations.  That's where things are going awry if I remember correctly.

Alternately, you could push on PM, releng, others to allow engineering to check this fix into RHEL 5 as it's blocking your rebase.  I'd go along with that suggestion from the engineering side.

Comment 12 Jeff Law 2013-04-10 20:41:50 UTC
I'll go ahead and take it since I've got the patches here already.

Comment 15 Martin Cermak 2013-04-12 13:13:51 UTC
*** Bug 951552 has been marked as a duplicate of this bug. ***

Comment 19 errata-xmlrpc 2013-09-30 22:11:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1306.html