[Bug gold/24803] gold should generate .debug_names
https://sourceware.org/bugzilla/show_bug.cgi?id=24803 --- Comment #1 from Tom Tromey --- In bug #24820, I'm rewriting the gdb .debug_names reader and writer to be closer to what is specified by DWARF. A few extensions are needed, so if this is ever implemented in gold, it should emit those as well. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31133] New: [riscv64] -z now breaks glibc testsuite
https://sourceware.org/bugzilla/show_bug.cgi?id=31133 Bug ID: 31133 Summary: [riscv64] -z now breaks glibc testsuite Product: binutils Version: 2.41 Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: aurelien at aurel32 dot net Target Milestone: --- Building glibc 2.38 with --enable-bind-now on riscv64 with the current binutils binutils-2_41-branch branch (actually through the sid debian package in version 2.41.50.20231206-1) causes the elf/tst-audit1 elf/tst-audit2 elf/tst-audit8 tests to fail with a segfault. Not using --enable-bind-now, that is not passing -z now to ld, workaround the issue. This is a regression from version 2.41, for which the tests pass with both with and without --enable-bind-now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31133] [riscv64] -z now breaks glibc testsuite
https://sourceware.org/bugzilla/show_bug.cgi?id=31133 Aurelien Jarno changed: What|Removed |Added Host||riscv64-unknown-linux-gnu Build||riscv64-unknown-linux-gnu Target||riscv64-unknown-linux-gnu -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31133] [riscv64] -z now breaks glibc testsuite
https://sourceware.org/bugzilla/show_bug.cgi?id=31133 --- Comment #1 from Aurelien Jarno --- Created attachment 15251 --> https://sourceware.org/bugzilla/attachment.cgi?id=15251&action=edit Reproducer I have attached a (big) reproduced for this bug. This is basically the files from the glibc build tree and the associated tests. Just use run.sh to link libc.so with and without -z now and see the difference in the testsuite result -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31130] Return of Stack Address in C_alloca
https://sourceware.org/bugzilla/show_bug.cgi?id=31130 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTABUG --- Comment #1 from Alan Modra --- (In reply to yuxuan He from comment #0) > hello, i found there is a return of stack address in function C_alloca No, you did not. See the definition of XNEWVEC. C_alloca is not what most people understand to be alloca. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31131] Potential Memory Leak in wrstabs.c
https://sourceware.org/bugzilla/show_bug.cgi?id=31131 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |OBSOLETE --- Comment #1 from Alan Modra --- Already fixed. 2.32 is old. You should look at current source if you want to help improve binutils. git clone https://sourceware.org/git/binutils-gdb.git -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31134] New: 2.41: build fails with --enable-warn-execstack
https://sourceware.org/bugzilla/show_bug.cgi?id=31134 Bug ID: 31134 Summary: 2.41: build fails with --enable-warn-execstack Product: binutils Version: 2.41 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: kloczko.tomasz at gmail dot com Target Milestone: --- Looks like ld build fails when source tree is configured with --enable-warn-execstack make[4]: Entering directory '/home/tkloczko/rpmbuild/BUILD/binutils-2.41/ld' /usr/bin/gcc -DHAVE_CONFIG_H -I. -I. -I. -I../bfd -I./../bfd -I./../include -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -DLOCALEDIR="\"/usr/share/locale\"" -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -DELF_LIST_OPTIONS=true -DELF_SHLIB_LIST_OPTIONS=true -DELF_PLT_UNWIND_LIST_OPTIONS=true -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -c -o eelf_x86_64.o eelf_x86_64.c eelf_x86_64.c: In function ‘gldelf_x86_64_before_parse’: eelf_x86_64.c:91:31: error: ‘DEFAULT_LD_ERROR_EXECSTACK’ undeclared (first use in this function); did you mean ‘DEFAULT_LD_WARN_EXECSTACK’? 91 | link_info.error_execstack = DEFAULT_LD_ERROR_EXECSTACK; | ^~ | DEFAULT_LD_WARN_EXECSTACK eelf_x86_64.c:91:31: note: each undeclared identifier is reported only once for each function it appears in eelf_x86_64.c:92:46: error: ‘DEFAULT_LD_ERROR_RWX_SEGMENTS’ undeclared (first use in this function); did you mean ‘DEFAULT_LD_WARN_RWX_SEGMENTS’? 92 | link_info.warn_is_error_for_rwx_segments = DEFAULT_LD_ERROR_RWX_SEGMENTS; | ^ | DEFAULT_LD_WARN_RWX_SEGMENTS make[4]: *** [Makefile:1599: eelf_x86_64.o] Error 1 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31134] 2.41: build fails with --enable-warn-execstack
https://sourceware.org/bugzilla/show_bug.cgi?id=31134 --- Comment #1 from kloczek --- Looks like DEFAULT_LD_ERROR_EXECSTACK is defined only when --disable-error-rwx-segments is used. [tkloczko@pers-jacek ld]$ grep -r DEFAULT_LD_ERROR_EXECSTACK emultempl/elf.em: link_info.error_execstack = DEFAULT_LD_ERROR_EXECSTACK; config.in:#undef DEFAULT_LD_ERROR_EXECSTACK configure.ac:AC_DEFINE_UNQUOTED(DEFAULT_LD_ERROR_EXECSTACK, config.h:/* #undef DEFAULT_LD_ERROR_EXECSTACK */ eelf_iamcu.c: link_info.error_execstack = DEFAULT_LD_ERROR_EXECSTACK; eelf_i386.c: link_info.error_execstack = DEFAULT_LD_ERROR_EXECSTACK; eelf32_x86_64.c: link_info.error_execstack = DEFAULT_LD_ERROR_EXECSTACK; eelf_x86_64.c: link_info.error_execstack = DEFAULT_LD_ERROR_EXECSTACK; -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31134] 2.41: build fails with --disable-warn-execstack
https://sourceware.org/bugzilla/show_bug.cgi?id=31134 kloczek changed: What|Removed |Added Summary|2.41: build fails with |2.41: build fails with |--enable-warn-execstack |--disable-warn-execstack -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31134] 2.41: build fails with --disable-warn-execstack
https://sourceware.org/bugzilla/show_bug.cgi?id=31134 --- Comment #2 from kloczek --- Correction when --enaable-warn-execstack -- You are receiving this mail because: You are on the CC list for the bug.
bfd_find_nearest_line() leaks memory due to dwarf_rnglists_buffer never being freed
Package: libbinutils Version: 2.41.50.20231206-1 Valgrind reports a leak when using bfd_find_nearest_line(): ==2681185== 145,802 bytes in 1 blocks are definitely lost in loss record 39 of 39 ==2681185==at 0x4840808: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==2681185==by 0x4FCA936: bfd_malloc (libbfd.c:290) ==2681185==by 0x5023665: read_section (dwarf2.c:737) ==2681185==by 0x5024E54: read_debug_rnglists (dwarf2.c:3181) ==2681185==by 0x5024E54: read_rnglists (dwarf2.c:3716) ==2681185==by 0x5026D42: read_rangelist (dwarf2.c:3791) ==2681185==by 0x5026D42: parse_comp_unit (dwarf2.c:4570) ==2681185==by 0x5026D42: stash_comp_unit (dwarf2.c:5589) ==2681185==by 0x502AB2A: _bfd_dwarf2_find_nearest_line_with_alt (dwarf2.c:5969) ==2681185==by 0x4FFDC56: _bfd_elf_find_nearest_line_with_alt (elf.c:10013) ==2681185==by 0x4FFDDC0: _bfd_elf_find_nearest_line (elf.c:9990) The program does call bfd_close(), but that single allocation is still leaked afterwards. I've traced this to dwarf_rnglists_buffer in dwarf2_debug_file never being freed. The following patch fixes it: --- a/bfd/dwarf2.c 2023-11-25 04:59:00.0 -0300 +++ b/bfd/dwarf2.c 2023-12-10 21:05:02.084673848 -0300 @@ -6123,6 +6123,7 @@ free (file->dwarf_line_str_buffer); free (file->dwarf_str_buffer); free (file->dwarf_ranges_buffer); + free (file->dwarf_rnglists_buffer); free (file->dwarf_line_buffer); free (file->dwarf_abbrev_buffer); free (file->dwarf_info_buffer); I don't provide a test case, but it's very easy to see that the pointer does get allocated but never gets freed anywhere, unlike its neighbours (e.g. dwarf_ranges_buffer is allocated and freed in exactly the same way). I've also tested the patch and the error goes away with it.
[Bug binutils/31131] Potential Memory Leak in wrstabs.c
https://sourceware.org/bugzilla/show_bug.cgi?id=31131 --- Comment #2 from yuxuan He <1157401338 at qq dot com> --- (In reply to Alan Modra from comment #1) > Already fixed. 2.32 is old. You should look at current source if you want > to help improve binutils. git clone > https://sourceware.org/git/binutils-gdb.git thanks for your reply. 2.32 is old but i've check this bug still existing in current version. and there are several system still use 2.32 as there default version.for example, ubuntu 18.04. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31131] Potential Memory Leak in wrstabs.c
https://sourceware.org/bugzilla/show_bug.cgi?id=31131 --- Comment #3 from yuxuan He <1157401338 at qq dot com> --- thanks for your reply. 2.32 is old but i've check this bug still existing in current version. and there are several system still use 2.32 as there default version.for example, ubuntu 18.04. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31130] Return of Stack Address in C_alloca
https://sourceware.org/bugzilla/show_bug.cgi?id=31130 --- Comment #2 from yuxuan He <1157401338 at qq dot com> --- actually, i don't mean that XNEWVEC return a stack address, i mean "depth" is stack address and it has been store into new_storage -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31130] Return of Stack Address in C_alloca
https://sourceware.org/bugzilla/show_bug.cgi?id=31130 --- Comment #3 from Alan Modra --- (In reply to yuxuan He from comment #2) > actually, i don't mean that XNEWVEC return a stack address, i mean "depth" > is stack address and it has been store into new_storage That too is not a problem. Given "char *p = C_alloca (size)", any access outside the range [p, p+size) is undefined behaviour. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31130] Return of Stack Address in C_alloca
https://sourceware.org/bugzilla/show_bug.cgi?id=31130 --- Comment #4 from yuxuan He <1157401338 at qq dot com> --- ok thanks -- You are receiving this mail because: You are on the CC list for the bug.
Re: bfd_find_nearest_line() leaks memory due to dwarf_rnglists_buffer never being freed
On Sun, Dec 10, 2023 at 09:45:32PM -0300, Konstantin Isakov wrote: > --- a/bfd/dwarf2.c 2023-11-25 04:59:00.0 -0300 > +++ b/bfd/dwarf2.c 2023-12-10 21:05:02.084673848 -0300 > @@ -6123,6 +6123,7 @@ >free (file->dwarf_line_str_buffer); >free (file->dwarf_str_buffer); >free (file->dwarf_ranges_buffer); > + free (file->dwarf_rnglists_buffer); >free (file->dwarf_line_buffer); >free (file->dwarf_abbrev_buffer); >free (file->dwarf_info_buffer); Thanks, I've committed this patch to current master. -- Alan Modra Australia Development Lab, IBM
