From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 918FE3858D1E for ; Tue, 18 Apr 2023 15:12:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 918FE3858D1E 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 C34331F8D9 for ; Tue, 18 Apr 2023 15:12:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1681830732; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type; bh=MXkvDAzwiMmzytyQcUEZNEi6TYQFo//2GX89D1nJ+j4=; b=NGyUB/rsXAsZPB6I4fcZdTN00bWwAMPV0INXWqcwfeVy4JbmSfi3/Tu0parcuJLMF4HJbi HvYy6FWrnyviuSYV5CAUh07GhdFvum8LBsEtOGmn9TD/6bwohNDqctw1x2p9eafBYbAcHt 618P7CqpdUNb6P3xu6QgognHN6GUb8o= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1681830732; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type; bh=MXkvDAzwiMmzytyQcUEZNEi6TYQFo//2GX89D1nJ+j4=; b=KgNYix4aPsgyo3o43OBwnhduNOfVvnTNHnCsrC44Bvi2G/oM25y/xMLbqah5ioJeL+xGD2 STXMWSerwQPqHoAQ== 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 B9E912C141 for ; Tue, 18 Apr 2023 15:12:12 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id B08A363D9; Tue, 18 Apr 2023 15:12:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id AF773633E for ; Tue, 18 Apr 2023 15:12:12 +0000 (UTC) Date: Tue, 18 Apr 2023 15:12:12 +0000 (UTC) From: Michael Matz To: binutils@sourceware.org Subject: [PATCH] section-select: Fix performance problem (PR30367) Message-ID: 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.2 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,T_SCC_BODY_TEXT_LINE 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: when using many wild-statements with non-wildcard filenames we were running into quadraticness via repeatedly using lookup_name on a long list of loaded files. I've originally retained using lookup_name because that preserved existing behaviour most obviously. In particular in matching wild-statements when using a non-wildcard filename it matches against local_sym_name, not the filename member. If the wildspec would have an archive-spec or a wildcard it would use the filename member, though. Also it would load the named file (and ignore it, as being not equal to the currently considered input-statement). Rewrite this to not use lookup_name but retain the comparison against local_sym_name with a comment to that effect. PR 30367 * ldlang.c (walk_wild_section_match): Don't use lookup_name but directly compare spec and local_sym_name. --- As the comment aludes to there is pre-existing inconsistency in that some cases used to (and still do) compare against input_statement->filename, and other cases against ->local_sym_name. Not just in section-matching but also other routines. In general the ->local_sym_name is the naming as given on cmdline or script (which may be "-lfoo"!) and ->filename is the one that's loaded from the filesystem, in particular may contain sysroot and search-dir directory prefixes. I'm not brave enough to change this with this patch, as all added consistency probably breaks currently working linker scripts people might have written over the years according to the current quirks. But, regression tested on 158 targets, and it fixes the noted performance problem. Okay for master? --- ld/ldlang.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/ld/ldlang.c b/ld/ldlang.c index b684e2d479a..4bec280b9df 100644 --- a/ld/ldlang.c +++ b/ld/ldlang.c @@ -433,10 +433,18 @@ walk_wild_section_match (lang_wild_statement_type *ptr, } else { - lang_input_statement_type *f; - /* Perform the iteration over a single file. */ - f = lookup_name (file_spec); - if (f != file) + /* XXX Matching against non-wildcard filename in wild statements + was done by going through lookup_name, which uses + ->local_sym_name to compare against, not ->filename. We retain + this behaviour even though the above code paths use filename. + It would be more logical to use it here as well, in which + case the above wildcarp() arm could be folded into this by using + name_match. This would also solve the worry of what to do + about unset local_sym_name (in which case lookup_name simply adds + the input file again). */ + const char *filename = file->local_sym_name; + if (filename == NULL + || filename_cmp (filename, file_spec) != 0) return; } -- 2.39.1