[Bug ld/28040] libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=28040
Nick Clifton changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED|REOPENED
CC||nickc at redhat dot com
--- Comment #15 from Nick Clifton ---
(In reply to H.J. Lu from comment #14)
Hi H.J.
With the patch applied the new linker tests are failing if you run them with
address sanitization enabled:
Executing on host: sh -c {./ld-new -o tmpdir/main.x -z norelro
-L/work/sources/binutils/branches/2.37/ld/testsuite/ld-plugin -plugin
/home/nickc/work/builds/binutils/branches/2.37/sanitize-address/ld/.libs/libldtestplug2.so.0
-plugin-opt registerclaimfile -plugin-opt registerallsymbolsread -plugin-opt
registercleanup -plugin-opt dumpresolutions tmpdir/main.o
/work/sources/binutils/branches/2.37/ld/testsuite/ld-plugin/func.c
tmpdir/text.o --defsym __stack_chk_fail=0 --defsym printf=main --defsym
puts=main 2>&1} /dev/null ld.tmp (timeout = 300)
spawn [open ...]
=
==4069616==ERROR: AddressSanitizer: heap-use-after-free on address
0x612005a0 at pc 0x00acfab5 bp 0x7ffd1f7e47b0 sp 0x7ffd1f7e47a0
READ of size 8 at 0x612005a0 thread T0
#0 0xacfab4 in bfd_plugin_close_file_descriptor
/work/sources/binutils/branches/2.37/bfd/plugin.c:288
#1 0x46ceb5 in release_plugin_file_descriptor
/work/sources/binutils/branches/2.37/ld/plugin.c:616
#2 0x46cf31 in release_input_file
/work/sources/binutils/branches/2.37/ld/plugin.c:627
#3 0x153a46ab3cdc in onall_symbols_read
/work/sources/binutils/branches/2.37/ld/testplug2.c:632
#4 0x4701b9 in plugin_call_all_symbols_read
/work/sources/binutils/branches/2.37/ld/plugin.c:1322
#5 0x445bda in lang_process
/work/sources/binutils/branches/2.37/ld/ldlang.c:7980
#6 0x450b1f in main /work/sources/binutils/branches/2.37/ld/ldmain.c:495
#7 0x153a49a94041 in __libc_start_main (/lib64/libc.so.6+0x27041)
#8 0x404bad in _start
(/home/nickc/work/builds/binutils/branches/2.37/sanitize-address/ld/ld-new+0x404bad)
0x612005a0 is located 224 bytes inside of 296-byte region
[0x612004c0,0x612005e8)
freed by thread T0 here:
#0 0x153a49cee2c7 in __interceptor_free (/lib64/libasan.so.6+0xb02c7)
#1 0x8af916 in _bfd_delete_bfd
/work/sources/binutils/branches/2.37/bfd/opncls.c:135
#2 0x8b103a in bfd_close_all_done
/work/sources/binutils/branches/2.37/bfd/opncls.c:852
#3 0x8b0f39 in bfd_close
/work/sources/binutils/branches/2.37/bfd/opncls.c:814
#4 0x4700de in plugin_maybe_claim
/work/sources/binutils/branches/2.37/ld/plugin.c:1301
#5 0x466a50 in ldfile_try_open_bfd
/work/sources/binutils/branches/2.37/ld/ldfile.c:320
#6 0x4670aa in ldfile_open_file
/work/sources/binutils/branches/2.37/ld/ldfile.c:403
#7 0x42e413 in load_symbols
/work/sources/binutils/branches/2.37/ld/ldlang.c:3024
#8 0x431267 in open_input_bfds
/work/sources/binutils/branches/2.37/ld/ldlang.c:3627
#9 0x445abb in lang_process
/work/sources/binutils/branches/2.37/ld/ldlang.c:7958
#10 0x450b1f in main /work/sources/binutils/branches/2.37/ld/ldmain.c:495
#11 0x153a49a94041 in __libc_start_main (/lib64/libc.so.6+0x27041)
previously allocated by thread T0 here:
#0 0x153a49cee627 in __interceptor_malloc (/lib64/libasan.so.6+0xb0627)
#1 0x89f874 in bfd_malloc
/work/sources/binutils/branches/2.37/bfd/libbfd.c:289
#2 0x89f98e in bfd_zmalloc
/work/sources/binutils/branches/2.37/bfd/libbfd.c:411
#3 0x8af397 in _bfd_new_bfd
/work/sources/binutils/branches/2.37/bfd/opncls.c:62
Please could you investigate ?
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/28040] libLLVM.so fails to link using LTO with ld.bfd + LLVMGold plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=28040 --- Comment #16 from H.J. Lu --- (In reply to Nick Clifton from comment #15) > (In reply to H.J. Lu from comment #14) > Hi H.J. > > With the patch applied the new linker tests are failing if you run them > with address sanitization enabled: > A patch is posted at https://sourceware.org/pipermail/binutils/2021-July/117281.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/28021] riscv: wrong double relaxation with LTO
https://sourceware.org/bugzilla/show_bug.cgi?id=28021 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Michael Matz : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=235f5ef4a6b8fbdcfaea8b629f7c6a9792a789de commit 235f5ef4a6b8fbdcfaea8b629f7c6a9792a789de Author: Michael Matz Date: Mon Jun 28 17:57:17 2021 +0200 elf/riscv: Fix relaxation with aliases [PR28021] the fix for PR22756 only changed behaviour for hidden aliases, but the same situation exists for non-hidden aliases: sym_hashes[] can contain multiple entries pointing to the same symbol structure leading to relaxation adjustment to be applied twice. Fix this by testing for duplicates for everything that looks like it has a version. PR ld/28021 bfd/ * elfnn-riscv.c (riscv_relax_delete_bytes): Check for any versioning. ld/ * testsuite/ld-riscv-elf/relax-twice.ver: New. * testsuite/ld-riscv-elf/relax-twice-1.s: New. * testsuite/ld-riscv-elf/relax-twice-2.s: New. * testsuite/ld-riscv-elf/ld-riscv-elf.exp (run_relax_twice_test): New, and call it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28053] [Patch] Minor typos in user-visible messages
https://sourceware.org/bugzilla/show_bug.cgi?id=28053 --- 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=579f0281f38afffe2ae5692f6ce61598c5dbfe8c commit 579f0281f38afffe2ae5692f6ce61598c5dbfe8c Author: Yuri Chornoivan Date: Tue Jul 6 14:56:05 2021 +0100 PR 28053: Fix spelling mistakes: usupported -> unsupported and relocatation -> relocation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28053] [Patch] Minor typos in user-visible messages
https://sourceware.org/bugzilla/show_bug.cgi?id=28053 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Hi Yuri, Thanks for alerting us to these spelling mistakes. I have now checked in your patch. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28052] [Patch] Minor typos in user-visible messages
https://sourceware.org/bugzilla/show_bug.cgi?id=28052 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Duplicate patch submission *** This bug has been marked as a duplicate of bug 28053 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/28053] [Patch] Minor typos in user-visible messages
https://sourceware.org/bugzilla/show_bug.cgi?id=28053 --- Comment #3 from Nick Clifton --- *** Bug 28052 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 gas/26406] Extreme assembling time regression with 2.35 and master
https://sourceware.org/bugzilla/show_bug.cgi?id=26406 Niklas Hambüchen changed: What|Removed |Added CC||mail at nh2 dot me -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28058] New: 300x performance regression in strip
https://sourceware.org/bugzilla/show_bug.cgi?id=28058 Bug ID: 28058 Summary: 300x performance regression in strip Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: mail at nh2 dot me Target Milestone: --- Dear maintainer, I found a performance regression between binutils 2.34 and 2.35.1 that makes stripping a 50 MB `.a` take 300 seconds instead of 1 second. Original investigation, including `.a` file for testing: https://github.com/NixOS/nixpkgs/issues/129467 I bisected the issue to this commit: a8e14f4cc2badfcf959f5e2cc57a941dc43f72d4 is the first bad commit commit a8e14f4cc2badfcf959f5e2cc57a941dc43f72d4 Author: Nick Clifton Date: Thu Mar 5 15:47:15 2020 + Add support for ELF files which contain multiple reloc sections which all target the same section. Note that this is the same commit that introduced the performance regression in `as` in this bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26406 However, the commit that fixed `as` in there does not fix this regression. I would appreciate if you could have a look! Niklas -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28058] 300x performance regression in strip
https://sourceware.org/bugzilla/show_bug.cgi?id=28058 Niklas Hambüchen changed: What|Removed |Added CC||mail at nh2 dot me -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28058] 300x performance regression in strip
https://sourceware.org/bugzilla/show_bug.cgi?id=28058 Niklas Hambüchen changed: What|Removed |Added CC||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28058] 300x performance regression in strip
https://sourceware.org/bugzilla/show_bug.cgi?id=28058 Niklas Hambüchen changed: What|Removed |Added CC||matz at suse dot de --- Comment #1 from Niklas Hambüchen --- Ah, master actually has a fix from 1 month ago that I hadn't spotted: commit 956ea65cd707707c0f725930214cbc781367a831 Author: Michael Matz Date: Mon Jun 7 15:52:31 2021 +0200 bfd/elf: Don't read non-existing secondary relocs Without this we unconditionally try to slurp in secondary relocs for each input section, leading to quadratic behaviour even for strip(1). On write-out we already used a flag to avoid this. So track existence of secondary relocs on read-in as well and only slurp in when needed. This still doesn't implement a proper list of secondary reloc sections, and still would exhibit quadratic behaviour if most input sections have a secondary reloc section. But at least on normal input this avoids any slowdown from trying to handle secondary relocation sections. It would be great if a point release could be made that includes it. Thank you! -- You are receiving this mail because: You are on the CC list for the bug.
