[Bug ld/14170] ld: assertion fail /export/gnu/import/git/binutils/bfd/linker.c:641
https://sourceware.org/bugzilla/show_bug.cgi?id=14170 --- 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=c7c970e4c63f81479539220874a98aa74bc0e090 commit c7c970e4c63f81479539220874a98aa74bc0e090 Author: Alan Modra Date: Mon Jun 22 11:50:46 2020 +0930 Correct bfin XPASSes bfin-elf and bfin-linux differ. This patch fixes these: bfin-linux-uclibc -XPASS: PR ld/14170 bfin-linux-uclibc -XPASS: pr17068 link --as-needed lib in group bfin-linux-uclibc -XPASS: -Bsymbolic-functions bfin-linux-uclibc -XPASS: pr22374 function pointer initialization * testsuite/ld-elf/shared.exp (pr14170): Clear xfail for bfin-*-linux*. (pr17068, symbolic-func.so, pr22374): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26154] New: nm-new: attempting free on address which was not malloc()
https://sourceware.org/bugzilla/show_bug.cgi?id=26154 Bug ID: 26154 Summary: nm-new: attempting free on address which was not malloc() Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: feidiyin at gmail dot com Target Milestone: --- Created attachment 12645 --> https://sourceware.org/bugzilla/attachment.cgi?id=12645=edit The Poc to trigger this bug When I was fuzzing nm-new with ASAN, I got this ERROR: ==1352==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0xf3f03b60 in thread T0 #0 0xf7ad1a84 in free (/usr/lib32/libasan.so.2+0x96a84) #1 0x84784a3 in _bfd_coff_free_symbols /home/yinqidi/experiment/binutils-2.34/bfd/coffgen.c:1782 #2 0x84784a3 in _bfd_coff_close_and_cleanup /home/yinqidi/experiment/binutils-2.34/bfd/coffgen.c:3180 #3 0x80b8254 in bfd_close_all_done /home/yinqidi/experiment/binutils-2.34/bfd/opncls.c:789 #4 0x80b8254 in bfd_close /home/yinqidi/experiment/binutils-2.34/bfd/opncls.c:759 #5 0x805ae7c in display_file /home/yinqidi/experiment/binutils-2.34/binutils/nm.c:1392 #6 0x804f335 in main /home/yinqidi/experiment/binutils-2.34/binutils/nm.c:1860 #7 0xf7898636 in __libc_start_main (/lib/i386-linux-gnu/libc.so.6+0x18636) #8 0x8050efb (/home/yinqidi/experiment/binutils-2.34/binutils/nm-new+0x8050efb) 0xf3f03b60 is located 736 bytes inside of 1745-byte region [0xf3f03880,0xf3f03f51) allocated by thread T0 here: #0 0xf7ad1f8e in calloc (/usr/lib32/libasan.so.2+0x96f8e) #1 0x80aae3e in bfd_malloc /home/yinqidi/experiment/binutils-2.34/bfd/libbfd.c:275 #2 0x80aae3e in bfd_zmalloc /home/yinqidi/experiment/binutils-2.34/bfd/libbfd.c:360 #3 0x867ba8b (/home/yinqidi/experiment/binutils-2.34/binutils/nm-new+0x867ba8b) SUMMARY: AddressSanitizer: bad-free ??:0 free ==1352==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26153] .gnu.version reported as orphan section even when not emitted
https://sourceware.org/bugzilla/show_bug.cgi?id=26153 Nick Desaulniers changed: What|Removed |Added CC||maskray at google dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26153] .gnu.version reported as orphan section even when not emitted
https://sourceware.org/bugzilla/show_bug.cgi?id=26153 Nick Desaulniers changed: What|Removed |Added CC||ndesaulniers at google dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26153] New: .gnu.version reported as orphan section even when not emitted
https://sourceware.org/bugzilla/show_bug.cgi?id=26153 Bug ID: 26153 Summary: .gnu.version reported as orphan section even when not emitted Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: kees at outflux dot net Target Milestone: --- For some reason ld.bfd with --orphan-handling=warn reports that .gnu.version* are orphans even though they are not being emitted. More complete details here: https://lore.kernel.org/lkml/202006221524.CEB86E036B@keescook/ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26141] -fvisibility=hidden generates JUMP11 relocations on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=26141 --- Comment #3 from Jason A. Donenfeld --- Hi Nick, Thanks for looking into this. I've uploaded a test script to reproduce the issue: https://sourceware.org/bugzilla/attachment.cgi?id=12644 You can see at the end of the script: + readelf -a linux-5.7.5/drivers/net/wireguard/wireguard.ko + grep R_ARM_THM_JUMP11 359e 00025166 R_ARM_THM_JUMP11 30e9 wg_packet_send_staged_ The kernel module loader then sees R_ARM_THM_JUMP11 and refuses to load it, because it doesn't do JUMP11 relocations. Removing the -fvisibility=hidden line restores the correct behavior of not adding those relocations. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26141] -fvisibility=hidden generates JUMP11 relocations on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=26141 --- Comment #2 from Jason A. Donenfeld --- Created attachment 12644 --> https://sourceware.org/bugzilla/attachment.cgi?id=12644=edit test script to reproduce issue -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26112] readelf --debug-dump=macro can't parse clang debug info
https://sourceware.org/bugzilla/show_bug.cgi?id=26112 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Tom, I have checked in a patch to add decoding of the DW_MACRO_define_strx and DW_MACRO_undef_strx opcodes. This should resolve the problem you found. Whilst working on this patch I also found that we had no way to decode the contents of the .debug_str_offsets section. So I have added a new command line option --debug-dump=str-offsets which can do this. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26112] readelf --debug-dump=macro can't parse clang debug info
https://sourceware.org/bugzilla/show_bug.cgi?id=26112 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e4b7104b1e0c70613d0f553cb18d25c7343647d3 commit e4b7104b1e0c70613d0f553cb18d25c7343647d3 Author: Nick Clifton Date: Mon Jun 22 17:44:56 2020 +0100 Add support for decoding the DW_MACRO_define_strx and DW_MACRO_undef_strx operands found in DWARF-5 .debug_macro sections. PR 26112 * dwarf.c (display_debug_str_offsets): Add code to display the contents of the .debug_str_offsets section. (display_debug_macro): Add support for DW_MACRO_define_strx and DW_MACRO_undef_strx. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/22136] Support marking "debug" info files with special ET_GNU_DEBUG_* values.
https://sourceware.org/bugzilla/show_bug.cgi?id=22136 Carlos O'Donell changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=26151 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #9 from Pekka Seppänen --- Created attachment 12643 --> https://sourceware.org/bugzilla/attachment.cgi?id=12643=edit Testcase: Misc. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #6 from Pekka Seppänen --- Created attachment 12640 --> https://sourceware.org/bugzilla/attachment.cgi?id=12640=edit Testcase -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #2 from Pekka Seppänen --- Created attachment 12636 --> https://sourceware.org/bugzilla/attachment.cgi?id=12636=edit Testcase -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #7 from Pekka Seppänen --- Created attachment 12641 --> https://sourceware.org/bugzilla/attachment.cgi?id=12641=edit Testcase -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #8 from Pekka Seppänen --- Created attachment 12642 --> https://sourceware.org/bugzilla/attachment.cgi?id=12642=edit Testcase: Driver -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #5 from Pekka Seppänen --- Created attachment 12639 --> https://sourceware.org/bugzilla/attachment.cgi?id=12639=edit Testcase -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #3 from Pekka Seppänen --- Created attachment 12637 --> https://sourceware.org/bugzilla/attachment.cgi?id=12637=edit Testcase -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #4 from Pekka Seppänen --- Created attachment 12638 --> https://sourceware.org/bugzilla/attachment.cgi?id=12638=edit Testcase -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=26150 --- Comment #1 from Pekka Seppänen --- Created attachment 12635 --> https://sourceware.org/bugzilla/attachment.cgi?id=12635=edit Testcase: Makefile -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26150] New: Assertion failure at ldlang.c:7269 when using inline assembly, -flto and --no-whole-archive
https://sourceware.org/bugzilla/show_bug.cgi?id=26150
Bug ID: 26150
Summary: Assertion failure at ldlang.c:7269 when using inline
assembly, -flto and --no-whole-archive
Product: binutils
Version: 2.35 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: pexu at sourceware dot mail.kapsi.fi
Target Milestone: ---
Target: aarch64-none-elf
Hi.
Hitting this assert on ldlang.c.
7269 ASSERT (entry->the_bfd->link.next == NULL);
I'm aware of https://sourceware.org/bugzilla/show_bug.cgi?id=26103, but this is
not related to link-once sections. Using binutils and GCC built from the
latest development tree.
I was able to able to narrow this issue down to inline assembly which
references an external object that resides inside the same library. An another
function must also reference that same object. Consider the following case
(header files omitted and assembly abbreviated):
libarchive0.a:
archive0__object0.c:
int archive0__object0(void) { return 42; }
archive0__object1.c:
__asm__("archive0__object1:" ";"
"b archive0__object0"); /* branch to archive0__object0 */
archive0__object2.c:
int archive0__object2(void) { return archive0__object0(); }
If archive0__object0 is referenced outside this library, everything works out
fine. However, if archive0__object0 is not referenced but archive0__object1
and archive0__object2 are, ld will trip the assertation.
Using -Wl,--trace I see a following pattern happening, I was lazy and simply
printf'd anything ldlang_add_entry was given. Basically two distinct
lang_input_statement_type objects reference the same bfd object; At some point
its link.next is set to a non-zero value (which seems to be valid value).
I will attach a brief test case; I only tried aarch64-none-elf, my apologies
for that.
.\libarchive0.a
@ add_archive_element: name=archive0__object1, abfd=@.
ldlang_add_entry(input=@
@: struct type: lang_input_statement_type
filename: .\archive0__object1.o
the_bfd: @
@: struct type: bfd
filename: .\archive0__object1.o (symbol from plugin)
usrdata:
next:
.\archive0__object1.o
.\archive0__object2.o
.\archive0__object0.o
.\libarchive0.a
@ add_archive_element: name=archive0__object1, abfd=@.
ldlang_add_entry(input=@)
@: struct type: lang_input_statement_type
filename: .\archive0__object1.o
the_bfd: @
@: struct type: bfd
filename: .\archive0__object1.o (symbol from plugin)
usrdata:
next:
@: struct type: bfd
filename: .\archive0__object2.o (symbol from plugin)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/26143] gas generates invalid line table entry
https://sourceware.org/bugzilla/show_bug.cgi?id=26143 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- (In reply to Tom de Vries from comment #0) Hi Tom, > [0x0080] Special opcode 75: advance Address by 5 to 0x1c and Line by > 0 to 12 > [0x0081] Extended opcode 1: End of Sequence > Every line number program sequence must end with a DW_LNE_end_sequence > instruction which creates a row whose address is that of the byte after the > last target machine instruction of the sequence. > One the one hand, the end-of-sequence declares that address 0x1c is one past > the byte of the last target machine instruction of the sequence. > > On the other hand, the special opcode declares a target instruction starting > at address 0x1c, that is part of that same sequence. Ah - but special opcodes do not necessarily assert that there is a target instruction starting at the address they reference. > This option causes a row to be added to .debug_line in reference to the > current address (which might not be the same as that of the following > assembly instruction), > I cannot tell from the formulation "in reference to the current address > (which might not be the same as that of the following assembly instruction)" > whether this particular instance of .loc usage is valid. My take on this is that the "view" directive specifies a property for an address, but it does not require that there be an instruction at that address. Hence the generated line number table is correct... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26141] -fvisibility=hidden generates JUMP11 relocations on ARM
https://sourceware.org/bugzilla/show_bug.cgi?id=26141 --- Comment #1 from Nick Clifton --- Hi Jason, Are you able to provide a small test case that demonstrates the problem ? Generating a JUMP11 reloc for hidden symbols should be safe, provided that the symbol is within a valid range. So the most likely problem is that the code for checking the range of the branch is broken. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26147] nm-new: heap-use-after-free in bfd/elf.c:2604 bfd_section_from_shdr
https://sourceware.org/bugzilla/show_bug.cgi?id=26147 --- Comment #2 from Yin Qidi --- How can I obtain the latest version(2.35) feidi...@gmail.com From: amodra at gmail dot com Date: 2020-06-22 15:13 To: feidiyin Subject: [Bug binutils/26147] nm-new: heap-use-after-free in bfd/elf.c:2604 bfd_section_from_shdr https://sourceware.org/bugzilla/show_bug.cgi?id=26147 Alan Modra changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Alan Modra --- This bug has already been fixed for 2.35 *** This bug has been marked as a duplicate of bug 26005 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26005] [size] crash with ASAN in bfd_section_from_shdr
https://sourceware.org/bugzilla/show_bug.cgi?id=26005 Alan Modra changed: What|Removed |Added CC||feidiyin at gmail dot com --- Comment #6 from Alan Modra --- *** Bug 26147 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26147] nm-new: heap-use-after-free in bfd/elf.c:2604 bfd_section_from_shdr
https://sourceware.org/bugzilla/show_bug.cgi?id=26147 Alan Modra changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Alan Modra --- This bug has already been fixed for 2.35 *** This bug has been marked as a duplicate of bug 26005 *** -- You are receiving this mail because: You are on the CC list for the bug.
