[Bug ld/28827] [2.38 Regression] ld hits assertion building LLVM 9 on powerpc64le-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=28827 --- Comment #10 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0acf434a23768449cbb4b3732355f3f2febecaee commit 0acf434a23768449cbb4b3732355f3f2febecaee Author: Alan Modra Date: Sat Feb 5 18:19:21 2022 +1030 Tweak assembler invocation for pr28827-1 test PR 28827 * testsuite/ld-powerpc/pr28827-1.d: Pass -a64 to gas. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28753] Heap-based Buffer Overflow in bfd_getl32
https://sourceware.org/bugzilla/show_bug.cgi?id=28753 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=cad4d6b91e97b6962807d33c04ed7e7797788438 commit cad4d6b91e97b6962807d33c04ed7e7797788438 Author: Alan Modra Date: Thu Jan 20 13:58:38 2022 +1030 PR28753, buffer overflow in read_section_stabs_debugging_info PR 28753 * rddbg.c (read_section_stabs_debugging_info): Don't read past end of section when concatentating stab strings. (cherry picked from commit 085b299b71721e15f5c5c5344dc3e4e4536dadba) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28826] [2.38 Regression] ld segfaults building xen
https://sourceware.org/bugzilla/show_bug.cgi?id=28826 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=61ecfbda44fb8d165f01cac3d704a5e9fd321795 commit 61ecfbda44fb8d165f01cac3d704a5e9fd321795 Author: Alan Modra Date: Fri Jan 28 14:29:34 2022 +1030 PR28826 x86_64 ld segfaults building xen Fallout from commit e86fc4a5bc37 PR 28826 * coffgen.c (coff_write_alien_symbol): Init dummy to zeros. (cherry picked from commit 07c9f243b3a12cc6749bc02ee7b165859979348b) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28827] [2.38 Regression] ld hits assertion building LLVM 9 on powerpc64le-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=28827 --- Comment #11 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d3ec1c514429b8c695974e785e47af8f71c388a2 commit d3ec1c514429b8c695974e785e47af8f71c388a2 Author: Alan Modra 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.
[Bug ld/28827] [2.38 Regression] ld hits assertion building LLVM 9 on powerpc64le-linux-gnu
https://sourceware.org/bugzilla/show_bug.cgi?id=28827 --- Comment #12 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0e24f6bd7f40acb1a6cf8046ba66e09e325e6f3b commit 0e24f6bd7f40acb1a6cf8046ba66e09e325e6f3b Author: Alan Modra Date: Sat Feb 5 15:36:58 2022 +1030 PR28827 testcase This testcase triggers a stub sizing error with the patches applied for PR28743 (commit 2f83249c13d8 and c804c6f98d34). PR 28827 * testsuite/ld-powerpc/pr28827-1.s, * testsuite/ld-powerpc/pr28827-1.d: New test. * testsuite/ld-powerpc/powerpc.exp: Run it. (cherry picked from commit 9810db10f726f47c8e878ca4b0b4b4f5e9c16a5d) (cherry picked from commit 0acf434a23768449cbb4b3732355f3f2febecaee) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28849] Symbols aren't properly loaded via --copy-dt-needed-entries
https://sourceware.org/bugzilla/show_bug.cgi?id=28849 --- Comment #8 from H.J. Lu --- (In reply to sandra from comment #7) > Backporting the fix to the older branch being used by our customer is > turning out to be a hard slog. Based on Joseph's test case, the patch seems > to be a good thing on the trunk, though, so I don't see any reason not to > commit it there. Is it possible to ask your customer to try the fix with master branch? I don't want to submit a patch which doesn't solve the real issue. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28849] Symbols aren't properly loaded via --copy-dt-needed-entries
https://sourceware.org/bugzilla/show_bug.cgi?id=28849 --- Comment #7 from sandra at codesourcery dot com --- Backporting the fix to the older branch being used by our customer is turning out to be a hard slog. Based on Joseph's test case, the patch seems to be a good thing on the trunk, though, so I don't see any reason not to commit it there. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 40987 in oss-fuzz: binutils:fuzz_objdump_safe: Direct-leak in xrealloc
Updates: Labels: Deadline-Approaching Comment #2 on issue 40987 by sheriffbot: binutils:fuzz_objdump_safe: Direct-leak in xrealloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40987#c2 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 40993 in oss-fuzz: binutils:fuzz_objdump_safe: Null-dereference READ in mips_gprel_reloc
Updates: Labels: Deadline-Approaching Comment #3 on issue 40993 by sheriffbot: binutils:fuzz_objdump_safe: Null-dereference READ in mips_gprel_reloc https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40993#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 40970 in oss-fuzz: binutils:fuzz_nm: Crash in filter_symbols
Updates: Labels: Deadline-Approaching Comment #3 on issue 40970 by sheriffbot: binutils:fuzz_nm: Crash in filter_symbols https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40970#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 40765 in oss-fuzz: binutils:fuzz_addr2line: Out-of-memory in fuzz_addr2line
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #4 on issue 40765 by sheriffbot: binutils:fuzz_addr2line: Out-of-memory in fuzz_addr2line https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40765#c4 This bug has exceeded our disclosure deadline. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 40967 in oss-fuzz: binutils:fuzz_addr2line: Heap-buffer-overflow in bfd_getl16
Updates: Labels: Deadline-Approaching Comment #3 on issue 40967 by sheriffbot: binutils:fuzz_addr2line: Heap-buffer-overflow in bfd_getl16 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40967#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug gas/28866] New: The results of "as" command are not consistent in arm and x86
https://sourceware.org/bugzilla/show_bug.cgi?id=28866 Bug ID: 28866 Summary: The results of "as" command are not consistent in arm and x86 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: panxh_ran at 163 dot com Target Milestone: --- Hello, the results of "as" command are not consistent in arm and x86. This is because md_shortopts and md_parse_option() are different in tc-aarch64.c and tc-i386.c. May I ask why does it have different values in arm and x86？ arm: #as -V as:unrecognized option '-V' x86: #as -V GNU assembler version 2.34 using BFD version (GNU Binutils) 2.34 arm: gas/config/tc-aarch64.c:9637:const char *md_shortopts = "m:"; x86: gas/config/tc-i386.c: #if defined (OBJ_ELF) || defined (OBJ_MAYBE_ELF) const char *md_shortopts = "kVQ:sqnO::"; #else const char *md_shortopts = "qnO::"; #endif -- You are receiving this mail because: You are on the CC list for the bug.
