From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id 3A8253858D1E for ; Wed, 19 Apr 2023 08:28:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3A8253858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-24736992dd3so1485097a91.1 for ; Wed, 19 Apr 2023 01:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681892913; x=1684484913; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=wD+muW2yoCohDNmN0Q8o9YAfT0OVUlQZjdRJuVNqJZ8=; b=JEZ47Hk+m94XRuWMmmg1xMwj3kssdUwUpWuTyaiZxTHCSravAtU/vDKkEhu9CPGb5I +i7tzp7dGnHGiXb+T0XD5YFzhppeMI5ocQkv7N8zj3iFaMrmfkVk3kElYgTfYPKDA/Rz QgQ9CGiDelAdXz7Yj66wHK4fcMOWqHT+F3CmzunSSvLkst2/j5orA70wwr1ETNYgtvPz OaGRzXMeZS0NXUTNPRpyw2Hb7kOZe819/jypY4Qj6hnqon+qaKwbiHheZ5uERKq/rSZH 57AO1RVCD2PnHQ2tV03AVmUqPLcHkOnKPPIUROpuk3pI5a1rtjZ2joZMaChWZujhFHUR 0UaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681892913; x=1684484913; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wD+muW2yoCohDNmN0Q8o9YAfT0OVUlQZjdRJuVNqJZ8=; b=MjlFgDJfuJsBk+UkKUtaMvR4LKQupcrK4BYR6fecPuXdZ2Ma4I/S+vTH/Sf9D0UWbb BUnkKZvWsUzFdpMyFaopKLnn/bvYiGPnF5Cv1TmjsAkRsRXaC04SiHg9aS3VtpTsKNmI LHGjkmwNh/cScJvrDqQj4yLWAPWcrB4qw5jN2G6MZneoYd28h7XK4aPBd99k6ZfhhHp9 fYMss+GY0XF6Nqs4oElC5yv/FHjCHYL33SC3cqMAUbHhMFGy003uXd69qXN55YPHFFEp mGi/xO2hD5fHYZWmaO5TI4TdZfFlelYva7k+EwulFY59FvcBaMFj0BD2sseIEjpGqm7b 4aPg== X-Gm-Message-State: AAQBX9doSWqmXUu180ZVWQdB72hgv+3dJAH+2nurkp3FArYjWmzN6xxy VRWdy5QfsyWwjJoIYhdfLK4jCfWkgfw= X-Google-Smtp-Source: AKy350b5Aq0g9vuc8NMwlcOs4WCbbiMlFMEQSKKLhekHXgsT7K4kt0xUsTThI6ZbOkhjjVXNqqYXAA== X-Received: by 2002:a17:90b:230b:b0:23d:3931:7b49 with SMTP id mt11-20020a17090b230b00b0023d39317b49mr2051546pjb.35.1681892912603; Wed, 19 Apr 2023 01:28:32 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id il7-20020a17090b164700b00247150f2091sm903894pjb.8.2023.04.19.01.28.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Apr 2023 01:28:31 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id C108D1140437; Wed, 19 Apr 2023 17:58:28 +0930 (ACST) Date: Wed, 19 Apr 2023 17:58:28 +0930 From: Alan Modra To: Michael Matz Cc: binutils@sourceware.org Subject: Re: [PATCH] section-select: Fix performance problem (PR30367) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3035.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,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: On Tue, Apr 18, 2023 at 03:12:12PM +0000, Michael Matz via Binutils wrote: > 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 any consistency changes were contemplated, I think I'd be inclined to replace filename with local_sym_name not the other way around. Also rename local_sym_name to cmdline_name, since there aren't any uses of local_sym_name as "Name to use for the symbol giving address of text start" as far as I'm aware. > 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? OK, but > --- > 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 this is fishy. :) ^^^^^^^^ > + 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 -- Alan Modra Australia Development Lab, IBM