[Bug gas/29494] Trailing jump table leads to "Error: unaligned opcodes detected in executable segment" on ARM thumb
https://sourceware.org/bugzilla/show_bug.cgi?id=29494 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- Created attachment 14290 --> https://sourceware.org/bugzilla/attachment.cgi?id=14290&action=edit Simpler patch Nick, I think you can just make use of line_delta == INT_MAX as a flag rather than setting a new one everywhere. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29505] xxx-w64-mingw32-objdump takes a long time to scan pe binaries for debug information
https://sourceware.org/bugzilla/show_bug.cgi?id=29505 --- Comment #3 from Ralf Habacker --- (In reply to Nick Clifton from comment #2) Hi Nick, > Please could you upload a copy of the bin/assistant.exe file so that I can > take a look ? The file is bigger than the 100k limit for adding attachments, so I can point you to an rpm archive where the requested file is included. Please search for `qttools-src-debug` at https://download.opensuse.org/repositories/windows:/mingw:/win32/openSUSE_Leap_15.3/noarch/, unpack the archive and see the file usr/i686-w64-mingw32/sys-root/mingw/bin/assistant-qt5.exe.debug inside the archive. > (I assume that this file demonstrates the slowness of objdump yes, when running the related commands in a chroot environment as reported. > as well it leaking memory). yes, also on the host > Is this a regression in performance compared to earlier binutils releases ? The usage of objdump for scanning binaries has been introduced recently, so there are no related information available > Plus is the 2.39 release any better than the 2.38 release ? no, there is no difference with binutils 2.39 $ /home/xxx/Downloads/usr/i686-w64-mingw32/bin/objdump -v GNU objdump (GNU Binutils) 2.39 > The memory leaks point a finger at the DWARF attribute parsing code, but I > suspect that more investigation will be needed to really narrow down the > problem. Looking at the the valgrind backtrace, the commit https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=9f272209118972864b2c3799ddf2b39683c1a7b7 may be related to this issue as it changes the affected location in read_and_display_attr_value(). Cheers Ralf -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29505] xxx-w64-mingw32-objdump takes a long time to scan pe binaries for debug information
https://sourceware.org/bugzilla/show_bug.cgi?id=29505 --- Comment #4 from Ralf Habacker --- (In reply to Ralf Habacker from comment #3) > Looking at the the valgrind backtrace, the commit > https://sourceware.org/git/?p=binutils-gdb.git;a=commit; > h=9f272209118972864b2c3799ddf2b39683c1a7b7 may be related to this issue as > it changes the affected location in read_and_display_attr_value(). > The memory leak seems to be fixed by the recently added commit https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=450da4bd38ae529a6879baafe59b1e88507b5fd9 > (process_debug_info): Use it when before clearing out unit > debug_information. Clear all fields. which is confirmed by valgrind ... ==5627== Command: /home/osc/build-root/openSUSE_Leap_15.3-x86_64/home/abuild/rpmbuild/BUILD/binutils-2.39/build/binutils/objdump -Wi /home/xxx/Downloads/usr/i686-w64-mingw32/sys-root/mingw/bin/assistant-qt5.exe.debug ==5627== ==5627== ==5627== HEAP SUMMARY: ==5627== in use at exit: 0 bytes in 0 blocks ==5627== total heap usage: 739,275 allocs, 739,275 frees, 125,827,392,706 bytes allocated ==5627== ==5627== All heap blocks were freed -- no leaks are possible I'm going to rebuild binutils 2.39 with this commit and will check if the performance issue is also fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29505] xxx-w64-mingw32-objdump takes a long time to scan pe binaries for debug information
https://sourceware.org/bugzilla/show_bug.cgi?id=29505 --- Comment #5 from Ralf Habacker --- (In reply to Ralf Habacker from comment #4) > > I'm going to rebuild binutils 2.39 with this commit and will check if the > performance issue is also fixed. It isn't fixed. The build log (https://build.opensuse.org/package/live_build_log/home:rhabacker:branches:windows:mingw:win32:binutils-2.39/mingw32-libqt5-qttools/openSUSE_Leap_15.3/x86_64) gives: [ 186s] + /usr/lib/rpm/mingw32-find-debuginfo.sh /home/abuild/rpmbuild/BUILD 1 [ 186s] extracting debug info from /home/abuild/rpmbuild/BUILDROOT/mingw32-libqt5-qttools-src-5.12.12-lp153.3.2.x86_64/usr/i686-w64-mingw32/sys-root/mingw/bin/assistant-qt5.exe [ 216s] ~/rpmbuild/BUILDROOT/mingw32-libqt5-qttools-src-5.12.12-lp153.3.2.x86_64/usr/i686-w64-mingw32/sys- i686-w64-mingw32-objdump still needs about 30s to scan assistant-qt5.exe, where it needs 2.8s when running on the host. $ time /home/osc/build-root/openSUSE_Leap_15.3-x86_64/home/abuild/rpmbuild/BUILD/binutils-2.39/build/binutils/objdump -Wi ~/Downloads/usr/i686-w64-mingw32/sys-root/mingw/bin/assistant-qt5.exe.debug > /dev/null real0m2,864s user0m2,816s sys 0m0,048s -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/6058] Linker segfaults with undefined weak function descriptors.
https://sourceware.org/bugzilla/show_bug.cgi?id=6058 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Alan Modra --- commit 906e58cab5ef included the attached patch, so segfault fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29494] Trailing jump table leads to "Error: unaligned opcodes detected in executable segment" on ARM thumb
https://sourceware.org/bugzilla/show_bug.cgi?id=29494 Nick Clifton changed: What|Removed |Added Last reconfirmed||2022-08-23 Assignee|unassigned at sourceware dot org |nickc at redhat dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #4 from Nick Clifton --- (In reply to Alan Modra from comment #3) > Nick, I think you can just make use of line_delta == INT_MAX as a flag > rather than setting a new one everywhere. Yeah - that is a better solution, thanks. Angus - would you be able to confirm that this patch solves your problem ? I am pretty confident that it works, but I would like some real-world assurance before committing it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29489] dlltool is not deterministic
https://sourceware.org/bugzilla/show_bug.cgi?id=29489 --- Comment #5 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=25ee24d990d6beb3fb01c673fcf13e0ea1522c5b commit 25ee24d990d6beb3fb01c673fcf13e0ea1522c5b Author: Nick Clifton Date: Tue Aug 23 09:54:52 2022 +0100 Add an option to dlltool to allow the creation of deterministic libraries. PR 29489 * dlltool.c (deterministic): New variable. (gen_lib_file): If deterministic is true set the BFD_DETERMINISTIC_OUTPUT flag. (usage): Mention --deterministic-libraries and --non-deterministic-libraries. (long_options): Add new options. (main): Parse new options. * doc/binutils.texi: Document the new options. * NEWS: Mention the new feature. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29489] dlltool is not deterministic
https://sourceware.org/bugzilla/show_bug.cgi?id=29489 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Nick Clifton --- Patch applied -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29505] xxx-w64-mingw32-objdump takes a long time to scan pe binaries for debug information
https://sourceware.org/bugzilla/show_bug.cgi?id=29505 --- Comment #6 from Nick Clifton --- (In reply to Ralf Habacker from comment #5) Hi Ralf, > i686-w64-mingw32-objdump still needs about 30s to scan assistant-qt5.exe, > where it needs 2.8s when running on the host. Sorry - I had not really grokked that this was a problem specific to the OBS build environment. Based upon your comments in the opensuse ticket, this is a problem with unaligned memory access, and possibly specific to the OBS environment running an unoptimized version of memset. Is this right ? If so are you able to enable profiling and find out which memset(s) are taking all the time ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29494] Trailing jump table leads to "Error: unaligned opcodes detected in executable segment" on ARM thumb
https://sourceware.org/bugzilla/show_bug.cgi?id=29494 --- Comment #5 from Angus Gratton --- Thanks heaps Nick for the patch. It's going to be a couple of days until I can test this, sorry. But I will definitely do so! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28917] ar: r does not replace objects specified multiple times on the command line
https://sourceware.org/bugzilla/show_bug.cgi?id=28917 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #3 from Alan Modra --- GNU ar was deliberately changed to allow multiple files with the same base name in commit 7f924d5516cf5 1996-10-01. That's when the comment was added about "compatibility with existing ar programs" too. I think we should leave things as they are. Posix says "It is unspecified whether multiple files in the archive may be identically named." Since we do allow that, it seems reasonable to make "ar -r archive.a a/foo.o b/foo.o" put both objects in the archive. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29512] ld non-canon ref to canon protected function check breaks Solaris/x86
https://sourceware.org/bugzilla/show_bug.cgi?id=29512 --- Comment #3 from Rainer Orth --- > --- Comment #2 from H.J. Lu --- > Created attachment 14288 > --> https://sourceware.org/bugzilla/attachment.cgi?id=14288&action=edit > A patch > > Try this. I've just successfully completed a i386-pc-solaris2.11 bootstrap. Looks good to go. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29505] xxx-w64-mingw32-objdump takes a long time to scan pe binaries for debug information
https://sourceware.org/bugzilla/show_bug.cgi?id=29505 --- Comment #7 from Ralf Habacker --- (In reply to Nick Clifton from comment #6) > (In reply to Ralf Habacker from comment #5) > Hi Ralf, > > > i686-w64-mingw32-objdump still needs about 30s to scan assistant-qt5.exe, > > where it needs 2.8s when running on the host. > > Sorry - I had not really grokked that this was a problem specific to the OBS > build environment. > Based upon your comments in the opensuse ticket, this is a problem with > unaligned memory access >From the screenshot appended to the associated opensuse bug https://bugzilla.opensuse.org/attachment.cgi?id=860901 it looks so. The functions __memset_avx2_unaligned_erms and __memset_avx2_erms are involved. > and possibly specific to the OBS environment As written in the description of this bug I was able to reproduce this issue also with a local chroot environment, so the issue is not obs specific. > running an unoptimized version of memset. If that is what the above mentioned functions do, then yes. > If so are you able to enable profiling and find out which memset(s) are > taking all the time ? You can see this at https://bugzilla.opensuse.org/attachment.cgi?id=860901 __memset_avx2_erms takes about 90% of the execution time and is called from __memset_avx2_unaligned_erms. > > Cheers > Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/29505] xxx-w64-mingw32-objdump takes a long time to scan pe binaries for debug information
https://sourceware.org/bugzilla/show_bug.cgi?id=29505
--- Comment #8 from Nick Clifton ---
(In reply to Ralf Habacker from comment #7)
Hi Ralf,
>> If so are you able to enable profiling and find out which memset(s) are
>> taking all the time ?
>
> You can see this at https://bugzilla.opensuse.org/attachment.cgi?id=860901
OK, so it looks like calls to an alloc() function inside
read_and_display_attr_value() are the source of the problem. There appear to
be two of these, one for allocating and extending the location list array and
one for allocating and extending the range list array. Neither of them are
particularly optimized.
Would you mind trying a small test ? Does this patch make any difference to
the performance ?
diff --git a/binutils/dwarf.c b/binutils/dwarf.c
index 71d8bc9ed5c..0fa4af9ac05 100644
--- a/binutils/dwarf.c
+++ b/binutils/dwarf.c
@@ -2855,7 +2855,7 @@ read_and_display_attr_value (unsigned long attribute,
if (lmax == 0 || num >= lmax)
{
- lmax += 1024;
+ lmax += 10240;
debug_info_p->loc_offsets = (uint64_t *)
xcrealloc (debug_info_p->loc_offsets,
lmax, sizeof (*debug_info_p->loc_offsets));
@@ -2929,7 +2929,7 @@ read_and_display_attr_value (unsigned long attribute,
if (lmax == 0 || num >= lmax)
{
- lmax += 1024;
+ lmax += 10240;
debug_info_p->range_lists = (uint64_t *)
xcrealloc (debug_info_p->range_lists,
lmax, sizeof (*debug_info_p->range_lists));
Cheers
Nick
--
You are receiving this mail because:
You are on the CC list for the bug.
Issue 47626 in oss-fuzz: binutils:fuzz_dlltool: Global-buffer-overflow in xstrdup
Updates: Labels: -restrict-view-commit -deadline-approaching Deadline-Exceeded Comment #4 on issue 47626 by sheriffbot: binutils:fuzz_dlltool: Global-buffer-overflow in xstrdup https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47626#c4 This bug has exceeded our disclosure deadline. 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 gas/29517] New: DWARF subprograms have a 'void' return type
https://sourceware.org/bugzilla/show_bug.cgi?id=29517 Bug ID: 29517 Summary: DWARF subprograms have a 'void' return type Product: binutils Version: 2.39 Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: kevinb at redhat dot com Target Milestone: --- We (myself and Frank Eigler) think we have found a problem with this commit: commit 591cc9fbbfd6d51131c0f1d4a92e7893edcc7a28 Author: Jan Beulich Date: Thu Apr 7 08:18:00 2022 +0200 gas/Dwarf: record functions To help tools like addr2line looking up function names, in particular when dealing with e.g. PE/COFF binaries (linked from ELF objects), where there's no ELF symbol table to fall back to, emit minimalistic information for functions marked as such and having their size specified. ... The GDB community recently encountered a regression when running the GDB testsuite on recent Fedora rawhide (rolling) releases which use binutils-2.39. The log file shows this failure: print /d (int) munmap (4198400, 4096) Invalid cast. (gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "(int) munmap (4198400, 4096)" Running GDB by hand with the testcase binary, I see: (gdb) ptype munmap type = void (void) This explains the reason for the failure: GDB doesn't let us cast a void to an int. Looking at the output (which ends up in the file "syms") produced by doing "maint print symbols syms" in GDB, I see: Symtab for file ../sysdeps/unix/syscall-template.S at 0x1149b90 Compilation directory is /usr/src/debug/glibc-2.36.9000-2.fc38.x86_64/misc Read from object file /lib64/ld-linux-x86-64.so.2 (0xfefbc0) Language: asm ... Blockvector: ... block #000, object at 0x16fd620, 1 syms/buckets in 0x77feb960..0x77feb984 ... void munmap(void); block object 0x16fd3a0, 0x77feb960..0x77feb984 section .text This tells us the name of the object file from where GDB obtained the symbols / debug info as well as reaffirming the fact that GDB thinks that the return type of munmap is 'void'. (According to its man page, the correct type of munmap should be int munmap(void *addr, size_t length).) Now, looking at "readelf -w /lib64/ld-linux-x86-64.so.2", we can find the CU and DIE for munmap: Compilation Unit @ offset 0x350ac: Length:0x61 (32-bit) Version: 5 Unit Type: DW_UT_compile (1) Abbrev Offset: 0xa21f Pointer Size: 8 <0><350b8>: Abbrev Number: 1 (DW_TAG_compile_unit) <350b9> DW_AT_stmt_list : 0x1f3fa <350bd> DW_AT_low_pc : 0x21960 <350c5> DW_AT_high_pc : 36 <350c6> DW_AT_name: (indirect string, offset: 0x186a): ../sysdeps/unix/syscall-template.S <350ca> DW_AT_comp_dir: (indirect string, offset: 0x26a9): /usr/src/debug/glibc-2.36.9000-2.fc38.x86_64/misc <350ce> DW_AT_producer: (indirect string, offset: 0x9f1): GNU AS 2.39 <350d2> DW_AT_language: 32769 (MIPS assembler) ... <1><350f2>: Abbrev Number: 2 (DW_TAG_subprogram) <350f3> DW_AT_name: (indirect string, offset: 0x6703): munmap <350f7> DW_AT_external: 0 <350f8> DW_AT_low_pc : 0x21960 <35100> DW_AT_high_pc : 36 Note that there's no DW_AT_type attribute (which would specify the return type) for the munmap subprogram. As I understand it, this causes the return type to be void. In section 3.3.2 of the DWARF 5 doc, it says "Debugging information entries for C void functions should not have an attribute for the return type." However, a potential fix is suggested by section 5.2: "An unspecified (implicit, unknown, ambiguous or nonexistent) type is represented by a debugging information entry with the tag DW_TAG_unspecified_type." Earlier Fedora releases including Fedora 35, 36, and 37 do not have a munmap subprogram in ld-linux-x86-64.so.2. For these releases, "ptype munmap" from within GDB shows "type = ()". GDB can cast the unknown return type to an int which avoids the "invalid cast" error that we are currently seeing on rawhide. This problem can be reproduced in a suitable environment by building upstream gdb and then, from within the 'gdb' directory, doing: make check TESTS=gdb.base/break-main-file-remove-fail.exp On rawhide, I see the following failures: FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: get integer valueof "(int) munmap (4198400, 4096)" FAIL: gdb.base/break-main-file-remove-fail.exp: file: get integer valueof "(int) munmap (4198400, 4096)" If you wish to run GDB by hand using the test case for this test, do: ./gdb -q testsuite/outputs/gdb.base/break-main-file-remove-fail/break-main-file-remove-fail Then... (gdb) b start Breakpoint 1 at 0x40113a: file /ironwood1/sourceware-git/rawhide-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break-main-file-remove-fail.c, line 26. (gdb) run Start
[Bug gas/29517] DWARF subprograms have a 'void' return type
https://sourceware.org/bugzilla/show_bug.cgi?id=29517 Kevin Buettner changed: What|Removed |Added CC||fche at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29517] DWARF subprograms output by gas-2.39 have a 'void' return type
https://sourceware.org/bugzilla/show_bug.cgi?id=29517 Kevin Buettner changed: What|Removed |Added Summary|DWARF subprograms have a|DWARF subprograms output by |'void' return type |gas-2.39 have a 'void' ||return type -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29517] DWARF subprograms output by gas-2.39 have a 'void' return type
https://sourceware.org/bugzilla/show_bug.cgi?id=29517 Kevin Buettner changed: What|Removed |Added CC||jbeulich at suse dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/14214] Internal error reported
https://sourceware.org/bugzilla/show_bug.cgi?id=14214 Alan Modra changed: What|Removed |Added Resolution|--- |OBSOLETE Status|NEW |RESOLVED --- Comment #1 from Alan Modra --- Doesn't seem to occur with current sources -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13799] linker crash in bfd_hash_lookup()
https://sourceware.org/bugzilla/show_bug.cgi?id=13799 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |OBSOLETE --- Comment #2 from Alan Modra --- valgrind doesn't give errors with current sources -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/13863] Allow alternative linker via LD_ALTEXEC environment variable
https://sourceware.org/bugzilla/show_bug.cgi?id=13863 Alan Modra changed: What|Removed |Added Resolution|--- |NOTABUG Status|NEW |RESOLVED --- Comment #1 from Alan Modra --- This can be implemeted easily with a shell script. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29448] aarch64: "has a LOAD segment with RWX permissions"
https://sourceware.org/bugzilla/show_bug.cgi?id=29448 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org See Also||https://github.com/OP-TEE/o ||ptee_os/issues/5471#issueco ||mment-1205362895 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29448] aarch64: "has a LOAD segment with RWX permissions"
https://sourceware.org/bugzilla/show_bug.cgi?id=29448 --- Comment #5 from Andrew Pinski --- The reasoning is because the max "page size" on aarch64 is set to 64k so there is only one segment. Either change the " . = ALIGN((1 << (12)));" to " . = ALIGN((1 << (14)));" Or use "-z max-page-size=4096" . -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29448] aarch64: "has a LOAD segment with RWX permissions"
https://sourceware.org/bugzilla/show_bug.cgi?id=29448 --- Comment #6 from Andrew Pinski --- (In reply to Jérôme Forissier from comment #4) > But then how is it that the LLVM linker (ld.lld) has no problem with that? > Same, linker script, and even same object files... (it generates 4 LOAD > segments instead of just 2). Because LLVM linker is set incorrectly for the max page size. It should be set to 64k as that as Linux supports 64k page size. See comment #5 otherwise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29517] DWARF subprograms output by gas-2.39 have a 'void' return type
https://sourceware.org/bugzilla/show_bug.cgi?id=29517 Florian Weimer changed: What|Removed |Added CC||fweimer at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/1046] Creates invalid Win32 applications (.exe) with gcc4
https://sourceware.org/bugzilla/show_bug.cgi?id=1046 Alan Modra changed: What|Removed |Added Resolution|--- |OBSOLETE Status|NEW |RESOLVED --- Comment #4 from Alan Modra --- Closing due to lack of any progress, and likely there is/was some sanity checking on number of sections in win32. The file format does restrict number of sections to 64k, but the testcase in comment #2 has 101 sections using a recent i686-w64-mingw32-gcc, suspiciously just over 100.. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/2596] Wrong code: linker relaxation for AVR
https://sourceware.org/bugzilla/show_bug.cgi?id=2596 Alan Modra changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Alan Modra --- Fixed with 731608473ad5 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/2609] XCOFF - loader reloc in unrecognized section `*ABS* error when using -bI
https://sourceware.org/bugzilla/show_bug.cgi?id=2609 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Alan Modra --- Seems to be fixed with current GNU ld. -- You are receiving this mail because: You are on the CC list for the bug.
