[Bug gas/30292] Unbounded recursion/infinite loop in eqv expansion since 4faaa10f3fabb345aca006ed67a8be97dc924e9c
https://sourceware.org/bugzilla/show_bug.cgi?id=30292 Jan Beulich changed: What|Removed |Added Assignee|unassigned at sourceware dot org |jbeulich at suse dot com CC|jbeulich at suse dot com | Target Milestone|--- |2.41 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40) since af31506c31a59a6edbb13498d6075fa704b801cd
https://sourceware.org/bugzilla/show_bug.cgi?id=30358 --- Comment #12 from Sam James --- Not tested the patch yet, but Matz, I'd like to say thanks for the insightful explanation. Really appreciated! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40) since af31506c31a59a6edbb13498d6075fa704b801cd
https://sourceware.org/bugzilla/show_bug.cgi?id=30358
--- Comment #11 from Michael Matz ---
The old (insertion-sort) code only added something to the output section list
if the considered section wasn't already either discarded or linked (by being
part of a group for instance). That is done by lang_add_section.
This output section list is the sorted container into which further insertions
are done (and hence its length is the one determining performance).
The binary search tree code always adds all candidates to the tree (which in
our
unlucky case here mostly degrades to a linked list), and only then goes through
that tree to linearize it to a list which doesn't contain the discarded or
already linked input sections (group members).
So, the intermediate tree contains things that aren't ultimately going to be
output, blowing performance down the drain. Otherwise the old insertion-sort
code and the now always used tree-based code are equivalent here. But the
example contains _many_ groups, and all of them have a .debug_macro section
(and only that!) and it exists in many input files, so the difference is
a search-chain length of about 1500 in the insertion sort case and about 106000
in the binary tree case, and that factor goes in quadraticly into performance
(as said, the search tree is degraded in the example).
So, the solution is obvious: don't add something to the tree if it won't be
added to the linearized list later. That requires some refactoring.
A hacky un-refactored patch for the above is below (relative to master).
It restores performance.
diff --git a/ld/ldlang.c b/ld/ldlang.c
index 4bec280b9df..7e0a9db51e3 100644
--- a/ld/ldlang.c
+++ b/ld/ldlang.c
@@ -687,6 +687,19 @@ output_section_callback_sort (lang_wild_statement_type
*ptr,
if (unique_section_p (section, os))
return;
+ /* Don't add sections to the tree when we already know that
+ lang_add_section won't do anything with it. */
+ if (section->output_section != NULL)
+{
+ if (!link_info.non_contiguous_regions)
+ return;
+
+ /* SECTION has already been handled in a special way
+(eg. LINK_ONCE): skip it. */
+ if (bfd_is_abs_section (section->output_section))
+ return;
+}
+
node = (lang_section_bst_type *) xmalloc (sizeof (lang_section_bst_type));
node->left = 0;
node->right = 0;
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/30292] Unbounded recursion/infinite loop in eqv expansion since 4faaa10f3fabb345aca006ed67a8be97dc924e9c
https://sourceware.org/bugzilla/show_bug.cgi?id=30292 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 ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40) since af31506c31a59a6edbb13498d6075fa704b801cd
https://sourceware.org/bugzilla/show_bug.cgi?id=30358 Michael Matz changed: What|Removed |Added Assignee|unassigned at sourceware dot org |matz at suse dot de Status|NEW |ASSIGNED --- Comment #10 from Michael Matz --- Yeah, that patch wouldn't help, it's in a different area. Thanks for the complete testcase. I'm going to have a look here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40) since af31506c31a59a6edbb13498d6075fa704b801cd
https://sourceware.org/bugzilla/show_bug.cgi?id=30358 Sam James changed: What|Removed |Added Summary|bfd very slow (> 4 minutes) |bfd very slow (> 4 minutes) |to link busybox with|to link busybox with |-Wl,--sort-section,alignmen |-Wl,--sort-section,alignmen |t (regression in|t (regression in |binutils-2.40) |binutils-2.40) since ||af31506c31a59a6edbb13498d60 ||75fa704b801cd -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30292] Unbounded recursion/infinite loop in eqv expansion since 4faaa10f3fabb345aca006ed67a8be97dc924e9c
https://sourceware.org/bugzilla/show_bug.cgi?id=30292 Sam James changed: What|Removed |Added Summary|Unbounded |Unbounded |recursion/infinite loop in |recursion/infinite loop in |eqv expansion |eqv expansion since ||4faaa10f3fabb345aca006ed67a ||8be97dc924e9c CC||jbeulich at suse dot com, ||sam at gentoo dot org --- Comment #2 from Sam James --- Potuz has analysed this in a dupe (PR30294): (In reply to Potuz from comment #0) > The [hashtree](https://github.com/prysmaticlabs/hashtree) fails to compile > since version 2.39 of binutils. GNU's assembler crashes with a SIGSEGV on an > infinite recursion expanding a macro. This regression was introduced in > [commit > 0x4faaa10f3fabb345aca006ed67a8be97dc924e9c](https://sourceware.org/git/ > ?p=binutils-gdb.git;a=commit;h=4faaa10f3fabb345aca006ed67a8be97dc924e9c). > > ## Steps to reproduce > > 1. Download [this file from > hashtree](https://github.com/prysmaticlabs/hashtree/blob/main/src/ > sha256_avx_x1.S) > 2. Try to compile it as > ``` > $ $ cc -c sha256_avx_x1.S > cc: internal compiler error: Segmentation fault signal terminated program as > ``` > > The infinite recursion happens expanding the macro that [rotates the > arguments](https://github.com/prysmaticlabs/hashtree/blob/main/src/ > sha256_avx_x1.S#L160-L170) and it recurses here > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/config/tc-i386- > intel.c;h=c139c584573c45e9779a583f12f6b6a0641c2844;hb=HEAD#l551 > > 3. Repeat 2 with the commit right before the one marked and compilation > succeeds. > > The above assembly is a mod of Intel's assembly from > https://github.com/intel/intel-ipsec-mb/blob/main/lib/avx_t1/ > sha256_one_block_avx.asm#L159-L171 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30292] Unbounded recursion/infinite loop in eqv expansion
https://sourceware.org/bugzilla/show_bug.cgi?id=30292 --- Comment #1 from Sam James --- *** Bug 30294 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/30294] Infinite recursion expanding macro
https://sourceware.org/bugzilla/show_bug.cgi?id=30294 Sam James changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||sam at gentoo dot org --- Comment #2 from Sam James --- I'll include this comment in the other bug. Thank you for the neat reproducer & bisect. *** This bug has been marked as a duplicate of bug 30292 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30292] Unbounded recursion/infinite loop in eqv expansion
https://sourceware.org/bugzilla/show_bug.cgi?id=30292 Potuz changed: What|Removed |Added CC||potuz at potuz dot net -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30294] Infinite recursion expanding macro
https://sourceware.org/bugzilla/show_bug.cgi?id=30294 Potuz 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 binutils/30355] [DWARFv5] readelf: loc_offset XX too big
https://sourceware.org/bugzilla/show_bug.cgi?id=30355 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nick Clifton --- [reproducer obtained offline] This was a silly snafu in the DWARF decoder. When decoding the DW_AT_loclistx attribute it was assuming that the .debug_loclists section were in DWARF v4 (or earlier) format, and not trying to access the index table. Fixed with a small patch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30355] [DWARFv5] readelf: loc_offset XX too big
https://sourceware.org/bugzilla/show_bug.cgi?id=30355 --- Comment #4 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=28ab94f51dcdee056d96e57ad04c27c22cf854ea commit 28ab94f51dcdee056d96e57ad04c27c22cf854ea Author: Nick Clifton Date: Wed Apr 19 11:48:24 2023 +0100 Fix: readelf: loc_offset XX too big PR 30355 * dwarf.c (read_and_display_attr_value): Correctly handle DW_loclistx attributes that index a version 5 .debug_loclists section. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30359] Create Resource-Only DLL
https://sourceware.org/bugzilla/show_bug.cgi?id=30359 --- Comment #3 from Nick Clifton --- (In reply to Pali Rohár from comment #2) > If adding empty import table and something in code .text sections is feature > of the linker, it is somewhere documented? No. :-( > What it is doing and what is > putting there (as those sections are not in any user supplied input file)? The (builtin, default) linker script is the cause. > And I'm interesting why it is doing, it is some requirement for some SW? > Just I'm currious here. The PE linker script automatically puts some constant values into the .text section as markers between the normal code and the constructors and destructors. If you run "ld --verbose" you will see this in the details for the .text section: ... LONG (-1); LONG (-1); KEEP (*(.ctors)); KEEP (*(.ctor)); KEEP (*(SORT_BY_NAME(.ctors.*))); LONG (0); LONG (0); /* See comment about __CTOR_LIST__ above. The same reasoning applies here too. */ ___DTOR_LIST__ = .; __DTOR_LIST__ = .; LONG (-1); LONG (-1); KEEP (*(.dtors)); KEEP (*(.dtor)); KEEP (*(SORT_BY_NAME(.dtors.*))); LONG (0); LONG (0); ... These markers are used by the execution startup code to help find the two tables. > And about objcopy --remove-section workaround, this is problematic because > for automatization, it is needed to know what sections has to be removed - > meaning ability to ask LD what additional section it added there. In which case, just use --only-section instead. ie: $ objcopy --only-section=.rsrc test-rsrc.dll test-rsrc.3.dll $ objdump -h test-rsrc.3.dll test-rsrc.3.dll: file format pei-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .rsrc 00b8 10003000 10003000 0200 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30248] Internal error in i386_att_operand
https://sourceware.org/bugzilla/show_bug.cgi?id=30248 Jan Beulich changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jan Beulich --- Should be okay now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30248] Internal error in i386_att_operand
https://sourceware.org/bugzilla/show_bug.cgi?id=30248
--- Comment #4 from cvs-commit at gcc dot gnu.org ---
The master branch has been updated by Jan Beulich :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4f0813127bc0c525fca152bca4fea30b7490ae14
commit 4f0813127bc0c525fca152bca4fea30b7490ae14
Author: Jan Beulich
Date: Wed Apr 19 11:43:26 2023 +0200
x86: parse_register() must not alter the parsed string
This reverts the code change done by 100f993c53a5 ("x86: Check
unbalanced braces in memory reference"), which wrongly identified
e87fb6a6d0cd ("x86/gas: support quoted address scale factor in AT
syntax") as the root cause of PR gas/30248. (The testcase is left in
place, no matter that it's at best marginally useful in that shape.)
The problem instead is that parse_register() alters the string handed to
it, thus breaking valid assumptions in subsequent parsing code. Since
the function's behavior is a result of get_symbol_name()'s, make a copy
of the incoming string before invoking that function.
Like for parse_real_register() follow the model of strtol() et al: input
string is const-qualified to signal that the string isn't altered, but
the returned "end" pointer is not const-qualified, requiring const to be
cast away (which generally is a bad idea, but the alternative would
again be more convoluted code).
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40)
https://sourceware.org/bugzilla/show_bug.cgi?id=30358 --- Comment #9 from Sam James --- The patch for bug 30367 (https://sourceware.org/pipermail/binutils/2023-April/127120.html) unfortunately doesn't help. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30367] Performance regression after updating to 2.40
https://sourceware.org/bugzilla/show_bug.cgi?id=30367 Sam James changed: What|Removed |Added CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40)
https://sourceware.org/bugzilla/show_bug.cgi?id=30358 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=30367 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30367] Performance regression after updating to 2.40
https://sourceware.org/bugzilla/show_bug.cgi?id=30367 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=30358 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40)
https://sourceware.org/bugzilla/show_bug.cgi?id=30358 Sam James changed: What|Removed |Added CC||matz at suse dot de --- Comment #8 from Sam James --- $ git bisect bad af31506c31a59a6edbb13498d6075fa704b801cd is the first bad commit commit af31506c31a59a6edbb13498d6075fa704b801cd Author: Michael Matz Date: Thu Nov 10 16:06:20 2022 +0100 Only use wild_sort_fast there's no reason why the tree-based variant can't always be used when sorting is required, it merely needs to also support filename sorting and have a fast path for insertion at end (aka rightmost tree leaf). The filename sorting isn't tested anywhere and the only scripttempl that uses it is avr (for 'SORT(*)(.ctors)'), and I believe even there it was a mistake. Either way, this adds a testcase for filename sorting as well. Then the non-BST based sorting can be simplified to only support the fast case of no sorting required at all (at the same time renaming the two variants to _sort and _nosort). ld/ldlang.c | 302 +++ ld/ldlang.h | 3 +- ld/testsuite/ld-scripts/sort-file.d | 18 +++ ld/testsuite/ld-scripts/sort-file.t | 6 + ld/testsuite/ld-scripts/sort-file1.s | 6 + ld/testsuite/ld-scripts/sort-file2.s | 6 + 6 files changed, 163 insertions(+), 178 deletions(-) create mode 100644 ld/testsuite/ld-scripts/sort-file.d create mode 100644 ld/testsuite/ld-scripts/sort-file.t create mode 100644 ld/testsuite/ld-scripts/sort-file1.s create mode 100644 ld/testsuite/ld-scripts/sort-file2.s -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/30358] bfd very slow (> 4 minutes) to link busybox with -Wl,--sort-section,alignment (regression in binutils-2.40)
https://sourceware.org/bugzilla/show_bug.cgi?id=30358 Sam James changed: What|Removed |Added Summary|bfd very slow (> 4 minutes) |bfd very slow (> 4 minutes) |to link busybox with|to link busybox with |-Wl,--sort-section,alignmen |-Wl,--sort-section,alignmen |t |t (regression in ||binutils-2.40) --- Comment #7 from Sam James --- binutils-2.39 completes quickly, binutils-2.40 doesn't. -- You are receiving this mail because: You are on the CC list for the bug.
