https://sourceware.org/bugzilla/show_bug.cgi?id=28827
--- Comment #11 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> --- The binutils-2_38-branch branch has been updated by Alan Modra <amo...@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d3ec1c514429b8c695974e785e47af8f71c388a2 commit d3ec1c514429b8c695974e785e47af8f71c388a2 Author: Alan Modra <amo...@gmail.com> Date: Fri Jan 28 09:46:13 2022 +1030 PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu The assertion is this one in ppc_build_one_stub BFD_ASSERT (stub_entry->stub_offset >= stub_entry->group->stub_sec->size); It is checking that a stub doesn't overwrite the tail of a previous stub, so not something trivial. Normally, stub sizing iterates until no stubs are added, detected by no change in stub section size. Iteration also continues if no stubs are added but one or more stubs increases in size, which also can be detected by a change in stub section size. But there is a pathological case where stub section sizing decreases one iteration then increases the next. To handle that situation, stub sizing also stops at more than STUB_SHRINK_ITER (20) iterations when calculated stub section size is smaller. The previous larger size is kept for the actual layout (so that building the stubs, which behaves like another iteration of stub sizing, will see the stub section sizes shrink). The problem with that stopping condition is that it assumes that stub sizing is only affected by addresses external to the stub sections, which isn't always true. This patch fixes that by also keeping larger individual stub_offset addresses past STUB_SHRINK_ITER. It also catches a further pathological case where one stub shrinks and another expands in such a way that no stub section size change is seen. PR 28827 * elf64-ppc.c (struct ppc_link_hash_table): Add stub_changed. (STUB_SHRINK_ITER): Move earlier in file. (ppc_size_one_stub): Detect any change in stub_offset. Keep larger one if past STUB_SHRINK_ITER. (ppc64_elf_size_stubs): Iterate on stub_changed too. (cherry picked from commit 0441f94fba61998b4bd18487aacf70a672df099c) Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu The previous patch wasn't quite correct. The size and padding depends on offset used in the current iteration, and if we're fudging the offset past STUB_SHRINK_ITER then we'd better use that offset. We can't have plt_stub_pad using stub_sec->size as the offset. PR 28827 * elf64-ppc.c (plt_stub_pad): Add stub_off param. (ppc_size_one_stub): Set up stub_offset to value used in this iteration before sizing the stub. Adjust plt_stub_pad calls. (cherry picked from commit 2405fc4016feadea33cb747d5654514f62b74ff4) Re: PR28827, assertion building LLVM 9 on powerpc64le-linux-gnu In trying to find a testcase for PR28827, I managed to hit a linker error in bfd_set_section_contents with a .branch_lt input section being too large for the output .branch_lt. bfd/ PR 28827 * elf64-ppc.c (ppc64_elf_size_stubs): Set section size to maxsize past STUB_SHRINK_ITER before laying out. Remove now unnecessary conditional setting of maxsize at start of loop. ld/ * testsuite/ld-powerpc/pr28827-2.d, * testsuite/ld-powerpc/pr28827-2.lnk, * testsuite/ld-powerpc/pr28827-2.s: New test. * testsuite/ld-powerpc/powerpc.exp: Run it. (cherry picked from commit 9ff8aa7d418bc508dbd429576b93e30ed9dc5891) -- You are receiving this mail because: You are on the CC list for the bug.