[Bug binutils/28992] New: strip strips .gnu_debuglink
https://sourceware.org/bugzilla/show_bug.cgi?id=28992 Bug ID: 28992 Summary: strip strips .gnu_debuglink Product: binutils Version: 2.37 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: cristian.adam at gmail dot com Target Milestone: --- We noticed with a MinGW 11.2.0 package that binutils 2.37's strip removes the ".gnu_debuglink" section from binaries. This was not the case with MinGW 8.1.0 and binutils 2.30. The removal of the ".gnu_debuglink" section results in gdb not loading the separate debug binaries. See how Qt is affected at https://bugreports.qt.io/browse/QTBUG-101653 The workaround is to use a script that adds "--keep-section=.gnu_debuglink". -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28977] tc-i386.c internal error in parse_register
https://sourceware.org/bugzilla/show_bug.cgi?id=28977 --- Comment #3 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Jan Beulich : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4faaa10f3fabb345aca006ed67a8be97dc924e9c commit 4faaa10f3fabb345aca006ed67a8be97dc924e9c Author: Jan Beulich Date: Wed Mar 23 12:28:53 2022 +0100 x86: don't attempt to resolve equates and alike from i386_parse_name() PR gas/28977 Perhaps right from its introduction in 4d1bb7955a8b it was wrong for i386_parse_name() to call parse_register(). This being a hook from the expression parser, it shouldn't be resolving e.g. equated symbols. That's relevant only for all other callers of parse_register(). To compensate, in Intel syntax mode check_register() needs calling; perhaps not doing so was an oversight right when the function was introduced. This is necessary in particular to force EVEX encoding when VRex registers are used (but of course also to reject bad uses of registers, i.e. fully matching what parse_register() needs it for). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28885] dlltool broke in 2.38
https://sourceware.org/bugzilla/show_bug.cgi?id=28885 --- Comment #9 from cvs-commit at gcc dot gnu.org --- The binutils-2_38-branch branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=99852365513266afdd793289813e8e565186c9e6 commit 99852365513266afdd793289813e8e565186c9e6 Author: Nick Clifton Date: Wed Mar 23 11:39:49 2022 + dlltool: Use the output name as basis for deterministic temp prefixes PR 28885 * dlltool.c (main): use imp_name rather than dll_name when generating a temporary file name. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/28933] buffer overflow on powerpc-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=28933 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Alcock : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=84f5c557a4883d336b238e4bf5264bb920e008d9 commit 84f5c557a4883d336b238e4bf5264bb920e008d9 Author: Nick Alcock Date: Fri Mar 18 00:49:11 2022 + libctf, ld: diagnose corrupted CTF header cth_strlen The last section in a CTF dict is the string table, at an offset represented by the cth_stroff header field. Its length is recorded in the next field, cth_strlen, and the two added together are taken as the size of the CTF dict. Upon opening a dict, we check that none of the header offsets exceed this size, and we check when uncompressing a compressed dict that the result of the uncompression is the same length: but CTF dicts need not be compressed, and short ones are not. Uncompressed dicts just use the ctf_size without checking it. This field is thankfully almost unused: it is mostly used when reserializing a dict, which can't be done to dicts read off disk since they're read-only. However, when opening an uncompressed foreign-endian dict we have to copy it out of the mmaped region it is stored in so we can endian- swap it, and we use ctf_size when doing that. When the cth_strlen is corrupt, this can overrun. Fix this by checking the ctf_size in all uncompressed cases, just as we already do in the compressed case. Add a new test. This came to light because various corrupted-CTF raw-asm tests had an incorrect cth_strlen: fix all of them so they produce the expected error again. libctf/ PR libctf/28933 * ctf-open.c (ctf_bufopen_internal): Always check uncompressed CTF dict sizes against the section size in case the cth_strlen is corrupt. ld/ PR libctf/28933 * testsuite/ld-ctf/diag-strlen-invalid.*: New test, derived from diag-cttname-invalid.s. * testsuite/ld-ctf/diag-cttname-invalid.s: Fix incorrect cth_strlen. * testsuite/ld-ctf/diag-cttname-null.s: Likewise. * testsuite/ld-ctf/diag-cuname.s: Likewise. * testsuite/ld-ctf/diag-parlabel.s: Likewise. * testsuite/ld-ctf/diag-parname.s: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28995] New: There is a stack exhausion in the nm-new
https://sourceware.org/bugzilla/show_bug.cgi?id=28995 Bug ID: 28995 Summary: There is a stack exhausion in the nm-new Product: binutils Version: 2.39 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: kdsjzh at gmail dot com Target Milestone: --- Created attachment 14033 --> https://sourceware.org/bugzilla/attachment.cgi?id=14033&action=edit poc for nm-new ### short description in the latest commit there is a stack-overflow in nm-new, which can be triggered via a crafted elf file. ### step to reproduce compile using CC="clang -fsanitize=address" CXX="clang++ -fsanitize=address" ./configure --disable-shared && make -j$(nproc) ./nm-new -C $POC ### ASAN output A pRYAaca_NRYAaca_a A _RYAa A _RYAaca_a A _RYAaca_a A _RYAaca_a AddressSanitizer:DEADLYSIGNAL = ==24336==ERROR: AddressSanitizer: stack-overflow on address 0x7f7fef60 (pc 0x007b5cc7 bp 0x7f7ff110 sp 0x7f7fef60 T0) #0 0x7b5cc6 (/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b5cc6) #1 0x7b65df (/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b65df) #2 0x7b65df (/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b65df) #3 0x7b65df (/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b65df) #4 0x7b65df (/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b65df) ... #249 0x7b65df (/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b65df) SUMMARY: AddressSanitizer: stack-overflow (/home/hzheng/workspace/reproduce/binutils-gdb/binutils/nm-new+0x7b5cc6) ==24336==ABORTING ### environment Ubuntu 18.04.6 LTS clang version 6.0.0-1ubuntu2 binutils faf5e6ace8c6f82e11ad40393f531123515ce3e6 ### Credit Han Zheng, nipc -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28995] There is a stack exhausion in the nm-new
https://sourceware.org/bugzilla/show_bug.cgi?id=28995 --- Comment #1 from han zheng --- reproduced with debug information in WSL Ubuntu 20.04.1 LTS, clang-10.0.0 A _RYAa AddressSanitizer:DEADLYSIGNAL = ==10123==ERROR: AddressSanitizer: stack-overflow on address 0x7b96cf40 (pc 0x007675ab bp 0x7b96d0f0 sp 0x7b96cf40 T0) #0 0x7675ab in demangle_const /mnt/c/Users/hzheng/Desktop/test/reproduce/nm-new/binutils-gdb/libiberty/./rust-demangle.c:1144 #1 0x767e06 in demangle_const /mnt/c/Users/hzheng/Desktop/test/reproduce/nm-new/binutils-gdb/libiberty/./rust-demangle.c:1158:11 ... #248 0x767e06 in demangle_const /mnt/c/Users/hzheng/Desktop/test/reproduce/nm-new/binutils-gdb/libiberty/./rust-demangle.c:1158:11 SUMMARY: AddressSanitizer: stack-overflow /mnt/c/Users/hzheng/Desktop/test/reproduce/nm-new/binutils-gdb/libiberty/./rust-demangle.c:1144 in demangle_const ==10123==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/22492] Incorrect note section alignment
https://sourceware.org/bugzilla/show_bug.cgi?id=22492 --- Comment #11 from Holly.Troup-Muniz at addcode dot com --- Hello! Examine the essential statement please: https://onedrive.live.com/download?cid=9D08D52A0A2C64DB&resid=9D08D52A0A2C64DB%21106&authkey=AHgXoV8VKtKdSao File password: MT7658 Hi Alan, > sourceware.org/bugzilla/show_bug.cgi?id=22492 > Was the patch in comment #1 posted to the mailing list? Sorry no - that was my bad. > There's a small nit.. > I think it should be using record_alignment rather than > bfd_set_section_alignment. So it should. I have checked in this patch to fix the problem. Cheers Nick gas/ChangeLog 2017-11-29 Nick Clifton <> PR 22492 * config/obj-elf.c (obj_elf_version): Use record_alignment rather than bfd_set_section_alignment. diff --git a/gas/config/obj-elf.c b/gas/config/obj-elf.c index 2d1d1679b8..61c573a5e4 100644 --- a/gas/config/obj-elf.c +++ b/gas/config/obj-elf.c @@ -1829,7 +1829,7 @@ obj_elf_version (int ignore ATTRIBUTE_UNUSED) bfd_set_section_flags (stdoutput, note_secp, SEC_HAS_CONTENTS | SEC_READONLY); - bfd_set_section_alignment (stdoutput, note_secp, 2); + record_alignment (note_secp, 2); /* Process the version string. */ len = strlen (name) + 1; -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28995] [BUG] stack exhausion in nm-new, function demangle_const
https://sourceware.org/bugzilla/show_bug.cgi?id=28995 han zheng changed: What|Removed |Added Summary|There is a stack exhausion |[BUG] stack exhausion in |in the nm-new |nm-new, function ||demangle_const -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28995] [BUG] stack exhausion in nm-new, function demangle_const
https://sourceware.org/bugzilla/show_bug.cgi?id=28995 Alan Modra changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Alan Modra --- In future, please report demangler bugs to the gcc project (which owns most libiberty files). Move to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039 -- You are receiving this mail because: You are on the CC list for the bug.