[Bug binutils/22911] Huge slowdown in objdump -d caused by scanning the dynamic relocs
https://sourceware.org/bugzilla/show_bug.cgi?id=22911 --- Comment #7 from Mark Wielaard --- (In reply to H.J. Lu from comment #6) > A patch is posted at > > https://sourceware.org/ml/binutils/2018-03/msg00015.html Thanks. With that patch my original testcase takes just 11 seconds (from 2 minutes 40 seconds) and the output is identical. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22911] Huge slowdown in objdump -d caused by scanning the dynamic relocs
https://sourceware.org/bugzilla/show_bug.cgi?id=22911 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=0e70b27ba900581df8e23cbbd4612176f869d796 commit 0e70b27ba900581df8e23cbbd4612176f869d796 Author: H.J. Lu Date: Mon Mar 5 03:44:46 2018 -0800 Use binary search on dynamic relocations Replace linear search with binary search on dynamic relocations. After finding a match, scan backward to the first matching relocation, then scan forward for a matching relocation with non-absolute symbol. On Fedora 27 x86-64, time for "objdump -d" on libxul.so from RHEL 7.4 x86-64 went from 134.46user 0.12system 2:15.03elapsed to 8.49user 0.14system 0:08.64elapsed PR binutils/22911 * objdump.c (is_significant_symbol_name): Return TRUE for all .plt* sections. (find_symbol_for_address): Replace linear search with binary search on dynamic relocations. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22911] Huge slowdown in objdump -d caused by scanning the dynamic relocs
https://sourceware.org/bugzilla/show_bug.cgi?id=22911 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from H.J. Lu --- Fixed for 2.31. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22923] readelf crashes with fuzzed samples 748 times
https://sourceware.org/bugzilla/show_bug.cgi?id=22923
--- Comment #8 from Paul Pluzhnikov ---
Can you test whether this patch:
$ git diff binutils/readelf.c
diff --git a/binutils/readelf.c b/binutils/readelf.c
index e3af50a9c9..b85db9f97c 100644
--- a/binutils/readelf.c
+++ b/binutils/readelf.c
@@ -10212,7 +10212,7 @@ process_dynamic_section (Filedata * filedata)
static char *
get_ver_flags (unsigned int flags)
{
- static char buff[32];
+ static char buff[128];
buff[0] = 0;
fixes some (or all) or the crashes you observed?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/22868] Gold does not select proper symbol visibility when used with LLVM gold-plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=22868
Michael Matz changed:
What|Removed |Added
CC||matz at suse dot de
--- Comment #1 from Michael Matz ---
The second testsuite fail in llvm has probably the same reason, but just for
completeness: visiblity.ll fails. It essentially has a weak and a non-weak
definition of the same symbol:
one.ll:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
define weak protected void @foo() {
ret void
}
two.ll:
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
define void @foo() {
ret void
}
But the linked result (with ld.gold):
Symbol {
Name: foo (44)
Value: 0x290
Size: 1
Binding: Weak (0x2)
Type: Function (0x2)
Other [ (0x3)
STV_PROTECTED (0x3)
]
Section: .text (0x5)
}
So the binding is weak. In ELF symbol resolution rules a non-weak definition
overrides a weak one, so it should actually be global. (In this case the
STV_PROTECTED is correct)
ld.bfd gets this right.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/22923] readelf crashes with fuzzed samples 748 times
https://sourceware.org/bugzilla/show_bug.cgi?id=22923
--- Comment #9 from calc.develop at web dot de ---
(In reply to Paul Pluzhnikov from comment #8)
> Can you test whether this patch:
>
> $ git diff binutils/readelf.c
> diff --git a/binutils/readelf.c b/binutils/readelf.c
> index e3af50a9c9..b85db9f97c 100644
> --- a/binutils/readelf.c
> +++ b/binutils/readelf.c
> @@ -10212,7 +10212,7 @@ process_dynamic_section (Filedata * filedata)
> static char *
> get_ver_flags (unsigned int flags)
> {
> - static char buff[32];
> + static char buff[128];
>
>buff[0] = 0;
>
>
> fixes some (or all) or the crashes you observed?
Looks good for a few randomly selected samples. I need to check in the next
days with all samples.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22920] Segfault in ld with RISC-V binary target
https://sourceware.org/bugzilla/show_bug.cgi?id=22920 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-06 CC||wilson at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jim Wilson --- Your linker script sets the output format to binary. Unfortunately, the current RISC-V linker only works for ELF output format. If you want non-elf output, you need to generate ELF first, and then use objcopy to convert it to another format. I've seen a few similar problems. There are srec testcases in the linker testsuite that fail because we can't produce srec directly. I think there is also a related bug report for this in the github riscv-binutils project. This should be fixed, but we have no time table for when it will be fixed, as we have many higher priority issues to look at first. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22920] Segfault in ld with RISC-V binary target
https://sourceware.org/bugzilla/show_bug.cgi?id=22920 --- Comment #2 from Geoffrey Allott --- Hi Jim, thanks for responding. Objcopy was indeed the way I ended up doing it - since it's a relatively simple workaround it makes sense that this is low priority, though an error message would have been useful here if it's known to be unimplemented. Sent from my Samsung Galaxy smartphone. Original message From: "wilson at gcc dot gnu.org" Date: 06/03/2018 1:11 am (GMT+00:00) To: geoffrey@allott.email Subject: [Bug ld/22920] Segfault in ld with RISC-V binary target https://sourceware.org/bugzilla/show_bug.cgi?id=22920 Jim Wilson changed: What |Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed| |2018-03-06 CC| |wilson at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jim Wilson --- Your linker script sets the output format to binary. Unfortunately, the current RISC-V linker only works for ELF output format. If you want non-elf output, you need to generate ELF first, and then use objcopy to convert it to another format. I've seen a few similar problems. There are srec testcases in the linker testsuite that fail because we can't produce srec directly. I think there is also a related bug report for this in the github riscv-binutils project. This should be fixed, but we have no time table for when it will be fixed, as we have many higher priority issues to look at first. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
