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
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.
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.
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.
Fixed
(In reply to Alan Modra from comment #4) > Fixed Thanks for you quick response.