[Bug ld/31652] weak def in discarded comdat section becomes unreferenced undefweak with ld -r
https://sourceware.org/bugzilla/show_bug.cgi?id=31652 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from H.J. Lu --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31652] weak def in discarded comdat section becomes unreferenced undefweak with ld -r
https://sourceware.org/bugzilla/show_bug.cgi?id=31652 --- Comment #2 from Sourceware Commits --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=eebad48ef858be83d754a6b1326133e51d36 commit eebad48ef858be83d754a6b1326133e51d36 Author: H.J. Lu Date: Thu Apr 18 05:28:56 2024 -0700 elf: Strip unreferenced weak undefined symbols Linker will resolve an undefined symbol only if it is referenced by relocation. Unreferenced weak undefined symbols serve no purpose. Weak undefined symbols appear in the dynamic symbol table only when they are referenced by dynamic relocation. Mark symbols with relocation and strip undefined weak symbols if they don't have relocation and aren't in the dynamic symbol table. bfd/ PR ld/31652 * elf-bfd.h (elf_link_hash_entry): Add has_reloc. * elf-vxworks.c (elf_vxworks_emit_relocs): Set has_reloc. * elflink.c (_bfd_elf_link_output_relocs): Likewise. (elf_link_output_extsym): Strip undefined weak symbols if they don't have relocation and aren't in the dynamic symbol table. ld/ PR ld/31652 * testsuite/ld-elf/elf.exp: Run undefweak tests. * testsuite/ld-elf/undefweak-1.rd: New file. * testsuite/ld-elf/undefweak-1a.s: Likewise. * testsuite/ld-elf/undefweak-1b.s: Likewise. * testsuite/ld-x86-64/weakundef-1.nd: Likewise. * testsuite/ld-x86-64/weakundef-1a.s: Likewise. * testsuite/ld-x86-64/weakundef-1b.s: Likewise. * testsuite/ld-x86-64/x86-64.exp: Run undefweak tests. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libsframe/31108] combined binutils+gcc build fails to install (libbfd installed before libsframe)
https://sourceware.org/bugzilla/show_bug.cgi?id=31108 Indu Bhagat changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #6 from Indu Bhagat --- Wont fix. Such a combined tree build is not officially supported. See https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644499.html for discussion on a similar issue involving gprofng. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libsframe/30014] FTBFS: install-strip fails because bfdlib relinks and fails to find libsframe
https://sourceware.org/bugzilla/show_bug.cgi?id=30014 Indu Bhagat changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Indu Bhagat --- Fixed in 2.40 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.43 Version|unspecified |2.43 (HEAD) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 --- Comment #16 from dave.anglin at bell dot net --- > --- Comment #15 from Nick Clifton --- > Patch applied. Thanks, Nick. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 67004 in oss-fuzz: binutils:fuzz_objdump: Abrt in aarch64_opcode_decode
Updates: Labels: -restrict-view-commit Comment #3 on issue 67004 by sheriffbot: binutils:fuzz_objdump: Abrt in aarch64_opcode_decode https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=67004#c3 This bug has been fixed. 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.
[Bug ld/31652] weak def in discarded comdat section becomes unreferenced undefweak with ld -r
https://sourceware.org/bugzilla/show_bug.cgi?id=31652 H.J. Lu changed: What|Removed |Added Target Milestone|--- |2.43 --- Comment #1 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2024-April/133694.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Nick Clifton --- Patch applied. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30743] FAIL: ld-elf/now-3 for hppa64-*-linux* target
https://sourceware.org/bugzilla/show_bug.cgi?id=30743 --- Comment #14 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=31d5afc19d98869aa13c3197f55b8a208fd19da2 commit 31d5afc19d98869aa13c3197f55b8a208fd19da2 Author: Nick Clifton Date: Thu Apr 18 13:24:42 2024 +0100 HPPA64 linker: Do not force the generation of DT_FLAGS for Linux targets. PR 30743 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31652] weak def in discarded comdat section becomes unreferenced undefweak with ld -r
https://sourceware.org/bugzilla/show_bug.cgi?id=31652 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31561] AArch64 gas test case "SME extension (ZERO)" fails on s390x
https://sourceware.org/bugzilla/show_bug.cgi?id=31561 Jens Remus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jens Remus --- Commited fix approved by Nick to mainline. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31654] gas: Bad SFrame information when assembling with listing
https://sourceware.org/bugzilla/show_bug.cgi?id=31654 --- Comment #1 from Jens Remus --- Following is an example on s390x. Note that the following patch series are required for s390x: - sframe: Enhancements to SFrame info generation https://sourceware.org/pipermail/binutils/2024-April/133591.html - s390: Initial support to generate SFrame info from CFI directives in assembler https://sourceware.org/pipermail/binutils/2024-April/133597.html With patch "gas: Skip SFrame FDE if FP without RA on stack" from above series reverted: $ cat test_fpra_min.s .cfi_sections .sframe, .eh_frame .cfi_startproc stmg%r11,%r15,88(%r15) .cfi_rel_offset 11, 88 .cfi_rel_offset 14, 112 la %r11,0 la %r14,0 .Lreturn: lmg %r11,%r15,88(%r15) .cfi_restore 14 .cfi_restore 11 br %r14 .cfi_endproc $ as test_fpra_min.s -o test_fpra_without-alh.o $ as -Wa,-alh test_fpra_min.s -o test_fpra_with_alh.o $ ojbdump --sframe test_fpra_without-alh.o ... Function Index : func idx [0]: pc = 0x0, size = 22 bytes STARTPC CFA FPRA sp+160u u 0006 sp+160c-72 c-48 0014 sp+160u u $ objdump --sframe test_fpra_with_alh.o ... Function Index : func idx [0]: pc = 0x0, size = 22 bytes STARTPC CFA FPRA sp+160u u 0006 sp+160u c-72 0006 sp+160c-72 c-48 0014 sp+160u c-72 0014 sp+160u u Note that the FP-tracking information erroneously being displayed in the RA-tracking column, is why the patch "gas: Skip SFrame FDE if FP without RA on stack" got introduced. The outputs of "objdump -Wf" and "objdump -WF" are identical in both cases (with and without option "-alh"). Debugging of the SFrame processing of the DWARF CFI instructions shows that with option "-a" there are additional DW_CFA_advance_loc: DW_CFA_def_cfa: reg=15 offset=160 DW_CFA_advance_loc: lab1=L0, lab2=L0 DW_CFA_offset: reg=11 offset=-72 DW_CFA_advance_loc: lab1=L0, lab2=L0 <-- only with -a DW_CFA_offset: reg=14 offset=-48 DW_CFA_advance_loc: lab1=L0, lab2=L0 DW_CFA_restore: reg=14 DW_CFA_advance_loc: lab1=L0, lab2=L0 <-- only with -a DW_CFA_restore: reg=11 Debugging of the CFI directive processing in gas/dw2gencfi.c shows the following: - With option "-a" cfi_add_advance_loc() is invoked more often in dot_cfi() due to the condition (symbol_get_frag (frchain_now->frch_cfi_data->last_address) != frag_now) evaluating to true. - output_cfi_insn() of case DW_CFA_advance_loc enters the condition (symbol_get_frag (to) == symbol_get_frag (from)) without option "-a" and enters the else condition with option "-a". The else path has an interesting comment that suggests that there is logic to relax an advance by zero at a later stage: "... Call frag_grow with the sum of room needed by frag_more and frag_var to preallocate space ensuring that the DW_CFA_advance_loc4 is in the fixed part of the rs_cfa frag, so that the relax machinery can remove the advance_loc should it advance by zero." I don't have a clue how to resolve this potential issue in the SFrame generation. I could not figure out how to detect the advance of zero in the SFrame processing of DW_CFA_advance_loc, so that it could be treated special. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31654] New: gas: Bad SFrame information when assembling with listing
https://sourceware.org/bugzilla/show_bug.cgi?id=31654 Bug ID: 31654 Summary: gas: Bad SFrame information when assembling with listing Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: jremus at linux dot ibm.com Target Milestone: --- The assembler generates bad SFrame information when assembling the following CFI directive sequence with option "-Wa,-a" to generate a listing on a SFrame enabled target that uses FP and RA tracking: .cfi_offset , .cfi_offset , This causes multiple SFrame FREs for the same PC start address to be generated. The reason is that with listings enabled there is an additional DWARF DW_CFA_advance_loc CFI instruction with zero advance between both DW_CFA_offset instructions, that the DWARF .eh_frame generator is able to process correctly, but causes the .sframe generator to choke. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31654] gas: Bad SFrame information when assembling with listing
https://sourceware.org/bugzilla/show_bug.cgi?id=31654 Jens Remus changed: What|Removed |Added CC||indu.bhagat at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31652] New: weak def in discarded comdat section becomes unreferenced undefweak with ld -r
https://sourceware.org/bugzilla/show_bug.cgi?id=31652 Bug ID: 31652 Summary: weak def in discarded comdat section becomes unreferenced undefweak with ld -r Product: binutils Version: 2.43 (HEAD) URL: https://sourceware.org/pipermail/binutils/2024-April/1 33602.html Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: aoliva at sourceware dot org Target Milestone: --- The following, say t.s, is dystilled from libstdc++-v3's floating_to_chars.o: .section .text.foobar,"axG",@progbits,foo,comdat .weak foo .type foo,@function foo: # .dc.a undef .size foo, . - foo .weak bar .set bar, foo The weak definitions were originally implicit instantiations of to_chars_i, and the aliases were originally meant for abi compatibility because of changes in int128_t mangling. The following, say m.s, is dystilled from a libstdc++-v3/testsuite/std/time/clock/system/io.cc: .section .text.foobar,"axG",@progbits,foo,comdat .weak foo .type foo,@function foo: .size foo, . - foo .global _start .set _start,foo And here's how to trigger the problem: (simplified from the emails, dropping the unnecessary archive and linking the object file in it directly; the asm sources were also simplified, dropping bits that were meant to pull t.o from the archive) gas/as-new t.s -o t.o && gas/as-new m.s -o m.o && ld/ld-new m.o t.o -o m -r && binutils/nm-new m | grep bar w bar Tested with 2.38, 2.42, and 2.42.50.20240413, targeting x86_64-linux-gnu, and also 2.42 targeting multiple vxworks7r2 targets. This is probably expected behavior: the weakly-defined symbol in t.o lives in a discarded section, so it decays to weak-undefined, and it most likely goes unnoticed on systems that support undefweak. If this were a final link, the bar symbol would be gone. So would the undef symbol, if the reference to it in t.s were uncommented. But because this is a relocatable link, both undefined symbols would remain. Both of them are a problem for e.g. vxworks kernel modules, that never undergo final linking, and whose loader rejects undefined symbols, even weak ones, if they're not defined elsewhere. I hoped --strip-discarded would get rid of undef, if not bar, but no such luck. -- You are receiving this mail because: You are on the CC list for the bug.
