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: | binutils | Assignee: | Jeff Law <law> |
Status: | CLOSED ERRATA | QA Contact: | Martin Cermak <mcermak> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 5.8 | CC: | 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: |
Forgot to mention that it happens on ppc64. It's a problem in the TLS optimizations. With some work it can be triggered on ppc32 as well. Created attachment 610607 [details]
Patch for ppc32 instance. Doesn't apply 100% cleanly, but can be fixed up by hand
Created attachment 610608 [details]
Patch for ppc32 instance. Doesn't apply 100% cleanly, but can be fixed up by hand
Created attachment 610611 [details]
Patch for ppc64 instance. Doesn't apply 100% cleanly, but can be fixed up by hand
Same problem with upcoming Firefox ESR rebase here: https://brewweb.devel.redhat.com/taskinfo?taskID=5034564 Hi, any update here? This bug blocks upcomming Firefox 17 security rebase. Is there any workaround available? Thanks! 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. (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. 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. I'll go ahead and take it since I've got the patches here already. *** Bug 951552 has been marked as a duplicate of this bug. *** 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 |
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