From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 8BFFE384EF7E for ; Fri, 25 Nov 2022 16:55:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8BFFE384EF7E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id C770A1FD86 for ; Fri, 25 Nov 2022 16:55:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1669395312; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xFJh0O9VxpfvrG0/IvBjN58otNH2icAML1kwD8xTug4=; b=KzrwaaUpofItZBCK+YxgtbQfgALRNfbcd/R+DZhuimVmbo+Ouh1gSPTpL9nKHOOhO/WP6O iwe+0AQEvvmfnp7k/n2NKLZzX+kMYTXL7t5Zh4LuBQZBZb0Ylua0McJiV4/xINbBeNTfx7 Plcs08rjJYJaotncrFvFWy2v7lpEmNM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1669395312; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xFJh0O9VxpfvrG0/IvBjN58otNH2icAML1kwD8xTug4=; b=HQv2QDiAdi16cTUmi5byxak1IZ+HCg+rC4F35t8DiPzFTT/hm61tS29aj94T/UWlIvOUfs yAVstmUDBRkd1cBw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id C2D432C141 for ; Fri, 25 Nov 2022 16:55:12 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id B9B886586; Fri, 25 Nov 2022 16:55:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id B85F76238 for ; Fri, 25 Nov 2022 16:55:12 +0000 (UTC) Date: Fri, 25 Nov 2022 16:55:12 +0000 (UTC) From: Michael Matz To: binutils@sourceware.org Subject: [PATCH 4/8] section-select: Completely rebuild matches In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: this resets all section matches before updating for newly created sections (i.e. completely rebuilds the matches). This fixes powerpc "TOC opt" tests that shows a difference in section order: originally .got of "linker stubs" comes before .toc (both placed into the same .got output section due to ".got {*(.got .toc)}". But .got of linker stubs is created later, and in the second run of resolve_wilds is appended to the list, hence is then coming after .toc (which was added already in the earlier resolve_wilds run). So order swapped -> test fails. The result would still work, and it's unclear if the documented meaning of multiple section selectors applies to lazily generated sections like here as well. For now lets reinstate old behaviour and simply always completely rebuild the matching sections. (Note: the reset lists aren't freed or reused) --- Alan: can you please take a look at the problem mentioned above? Without this patch the "TOC opt" tests fails on powerpc because two sections are swapped. But it's not quite clear if lazily added sections (.got of "linker stubs") are also bound to the documented behaviour of multiple globs in a single wild statement. The result with the changed section order would continue to work, and if we could decide that that's okay the section resolution wouldn't have to rebuild stuff from scratch, roughly halving the time for it. In that case I wouldn't patch 7/8 to remove the libbfd interface to get the max section id and instead use it for early outs. Sections that are generated late and lazy would then always be appended to their matching wild statement. Ciao, Michael. ld/ldlang.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/ld/ldlang.c b/ld/ldlang.c index 06fa541df3a..57432700a18 100644 --- a/ld/ldlang.c +++ b/ld/ldlang.c @@ -8400,6 +8400,26 @@ lang_propagate_lma_regions (void) } } +static void +reset_one_wild (lang_statement_union_type *statement) +{ + if (statement->header.type == lang_wild_statement_enum) + { + lang_wild_statement_type *stmt = &statement->wild_statement; + stmt->resolved = false; + stmt->max_section_id = 0; + /* XXX Leaks? */ + lang_list_init (&stmt->matching_sections); + } +} + +static void +reset_resolved_wilds (void) +{ + lang_for_each_statement (reset_one_wild); + old_max_section_id = 0; +} + void lang_process (void) { @@ -8618,6 +8638,7 @@ lang_process (void) ldemul_after_check_relocs (); + reset_resolved_wilds (); resolve_wilds (); /* Update wild statements in case the user gave --sort-section. -- 2.36.1