Bug 20886

Summary: [2.23][ppc64le] ld hangs (indefinite loop) in ppc64_elf_size_stubs
Product: binutils Reporter: Xingxing Pan <xingxing.pan>
Component: ldAssignee: Alan Modra <amodra>
Status: RESOLVED FIXED    
Severity: critical CC: amodra
Priority: P2    
Version: 2.23   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed: 2016-11-30 00:00:00

Description Xingxing Pan 2016-11-30 02:42:51 UTC
GNU ld 2.23 hangs in ppc64_elf_size_stubs when linking the objects in https://ibm.box.com/shared/static/0lk5kd0dosut39ythuvfsudv2a8e07t1.gz

Environment:
$ cat /etc/os-release 
NAME="Red Hat Enterprise Linux Server"
VERSION="7.1 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="7.1"
PRETTY_NAME="Red Hat Enterprise Linux Server 7.1 (Maipo)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.1:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.1
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION=7.1
$ uname -a
Linux lswgc3.torolab.ibm.com 3.10.0-229.ael7b.ppc64le #1 SMP Fri Jan 30 12:03:50 EST 2015 ppc64le ppc64le ppc64le GNU/Linux
$ rpm -q --whatprovides /usr/bin/ld
binutils-2.23.52.0.1-30.ael7b.ppc64le

Steps to reproduce:
1) wget https://ibm.box.com/shared/static/0lk5kd0dosut39ythuvfsudv2a8e07t1.gz
2) tar -xf 0lk5kd0dosut39ythuvfsudv2a8e07t1.gz
3) cd 137582
4) /usr/bin/ld --eh-frame-hdr -Qy -melf64lppc -L./libs/ ./libs/crt1.o ./libs/crti.o ./libs/crtbegin.o --no-toc-optimize ./libs/libipaobjects.a   -o ./libs/ipa64 -lrt -lflt_64 -li64_64 -lm -ldl -lpthread -lbifs64 -lTransformationReportInterface64 -lListerInterface64 ./libs/libtcmalloc_minimal.a -dynamic-linker ./libs/ld64.so.2 --enable-new-dtags -static -lxlopt -lxl -libmc++ -call_shared -lstdc++ -lm --as-needed -ldl --no-as-needed -lgcc_s -lgcc --as-needed -lpthread --no-as-needed -lm -lc -lgcc_s -lgcc ./libs/crtend.o ./libs/crtn.o
Comment 1 Alan Modra 2016-11-30 04:46:03 UTC
Confirmed with current master too.  The binary is large enough that there are two stub sections servicing .text (which is 88M) and it so happens that between one iteration of sizing and the next that one stub section grows while the other shrinks.  Since one section is always growing, the loop never terminates..  I'll need to change the algorithm to not update previous size on shrinking, once we go past a certain number of iterations.
Comment 2 Sourceware Commits 2016-11-30 06:30:34 UTC
The master branch has been updated by Alan Modra <amodra@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ea3d7d1cab4221ab729327bb4d957352c79d05f0

commit ea3d7d1cab4221ab729327bb4d957352c79d05f0
Author: Alan Modra <amodra@gmail.com>
Date:   Wed Nov 30 15:33:07 2016 +1030

    PR20886, looping in ppc64_elf_size_stubs
    
    The PR20886 binary is large enough that there are two stub sections
    servicing .text (which is 88M).  It so happens that between one
    iteration of sizing and the next that one stub section grows while
    the other shrinks.  Since one section is always growing, the loop
    never terminates.
    
    This patch changes the algorithm to not update previous size on
    shrinking, once we go past a certain number of iterations.
    
    	PR ld/20886
    	* elf64-ppc.c (ppc64_elf_size_stubs): Make rawsize max size seen
    	on any pass past STUB_SHRINK_ITER.
Comment 3 Sourceware Commits 2016-11-30 06:35:03 UTC
The binutils-2_27-branch branch has been updated by Alan Modra <amodra@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5d1f2ede8f0de48b90fd18a81f67382dc99661dc

commit 5d1f2ede8f0de48b90fd18a81f67382dc99661dc
Author: Alan Modra <amodra@gmail.com>
Date:   Wed Nov 30 15:33:07 2016 +1030

    PR20886, looping in ppc64_elf_size_stubs
    
    The PR20886 binary is large enough that there are two stub sections
    servicing .text (which is 88M).  It so happens that between one
    iteration of sizing and the next that one stub section grows while
    the other shrinks.  Since one section is always growing, the loop
    never terminates.
    
    This patch changes the algorithm to not update previous size on
    shrinking, once we go past a certain number of iterations.
    
    	PR ld/20886
    	* elf64-ppc.c (ppc64_elf_size_stubs): Make rawsize max size seen
    	on any pass past STUB_SHRINK_ITER.
Comment 4 Alan Modra 2016-11-30 06:42:50 UTC
Fixed
Comment 5 Xingxing Pan 2016-12-01 05:24:04 UTC
(In reply to Alan Modra from comment #4)
> Fixed

Thanks for you quick response.