From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) by sourceware.org (Postfix) with ESMTPS id 858703870891 for ; Wed, 2 Sep 2020 13:05:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 858703870891 Received: by mail-pl1-x643.google.com with SMTP id y6so2269039plt.3 for ; Wed, 02 Sep 2020 06:05:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=5j2kGXmMWZo+c9LcSoF2v5ugGn8V6mBAuWJCVjHt/pk=; b=YgegBP5Sc5THKKFn+D1yMKJYXjp0PgFvcvungf2EI/DqG8MZ9RtEtDpz7jYv202u0L EdrvLZFMaPB2D05ZfKiQYiVSYAe9ClrbP7YNfht/idmNLjnx1w0uCyJhssnJNRuXiX/1 W/ZwAq8mV0zrI/ApcwpRSiF4CRzUofDqErgrYcGmKJi0gMeks+/BQSyFFrYAbzqOu0a5 alNz8slnW2oWqRTe+j79wLFCvs5BeVsprrT14ICO8k7sD8mLslZGMV3dXN81kW8tLAWW bKFvUhjdvR8LeA7qy/2eva0hcEfrWP1ZBvAdvb/uA/n4+PHRzVE5xS7mMURsOJT/ZKes OAkA== X-Gm-Message-State: AOAM530z0hQkIh8+q1OrzSoUlhm9GYm4UZwvlv7r3MCHPKyI8dyRoPNH gamODLcc3w8qhGFQH+fxi+k= X-Google-Smtp-Source: ABdhPJztHWVt8IEyLllTgH+c9pW3fz7+O04dSrcMjyoO0V4mfo0AudiHmpXQjSJpDNIzl89LX5Pecw== X-Received: by 2002:a17:90b:796:: with SMTP id l22mr2183239pjz.199.1599051929636; Wed, 02 Sep 2020 06:05:29 -0700 (PDT) Received: from bubble.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id c145sm5442769pfb.62.2020.09.02.06.05.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Sep 2020 06:05:28 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 603B18796C; Wed, 2 Sep 2020 22:35:23 +0930 (ACST) Date: Wed, 2 Sep 2020 22:35:22 +0930 From: Alan Modra To: "H.J. Lu" Cc: Martin =?utf-8?B?TGnFoWth?= , Binutils Subject: Re: [PATCH] elf: Don't load archive element after dynamic definition Message-ID: <20200902130522.GI15695@bubble.grove.modra.org> References: <20200825172842.1212936-1-hjl.tools@gmail.com> <20200827135311.GD15695@bubble.grove.modra.org> <20200828015847.GG15695@bubble.grove.modra.org> <20200828144914.GP15695@bubble.grove.modra.org> <20200902081225.GH15695@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-12.6 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 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2020 13:05:32 -0000 On Wed, Sep 02, 2020 at 04:56:48AM -0700, H.J. Lu wrote: > On Wed, Sep 2, 2020 at 1:12 AM Alan Modra wrote: > > > > On Wed, Sep 02, 2020 at 08:52:06AM +0200, Martin Liška wrote: > > > On 8/28/20 4:50 PM, H.J. Lu via Binutils wrote: > > > > PR ld/26530 test still failed. > > > > > > Hello. > > > > > > Is there any progress on this please? > > > > I think what we want is the following, and some tweaking of the > > testsuite to remove FAIL: PR ld/15146 (1). That test relied on not > > loading a shared lib due to an IR symbol reference, but the logic > > added by git commit 3d5bef4c0871 has already been reverted. > > > > diff --git a/bfd/elflink.c b/bfd/elflink.c > > index 5c085b14b7..346f534911 100644 > > --- a/bfd/elflink.c > > +++ b/bfd/elflink.c > > @@ -4977,11 +4977,7 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info) > > object and a shared object. */ > > bfd_boolean dynsym = FALSE; > > > > - /* Plugin symbols aren't normal. Don't set def_regular or > > - ref_regular for them, or make them dynamic. */ > > - if ((abfd->flags & BFD_PLUGIN) != 0) > > - ; > > - else if (! dynamic) > > + if (! dynamic) > > { > > if (! definition) > > { > > @@ -5162,10 +5158,6 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info) > > && !bfd_link_relocatable (info)) > > dynsym = FALSE; > > > > - /* Nor should we make plugin symbols dynamic. */ > > - if ((abfd->flags & BFD_PLUGIN) != 0) > > - dynsym = FALSE; > > - > > if (definition) > > { > > h->target_internal = isym->st_target_internal; > > @@ -5192,7 +5184,7 @@ elf_link_add_object_symbols (bfd *abfd, struct bfd_link_info *info) > > } > > } > > > > - if (dynsym && h->dynindx == -1) > > + if (dynsym && (abfd->flags & BFD_PLUGIN) == 0 && h->dynindx == -1) > > { > > if (! bfd_elf_link_record_dynamic_symbol (info, h)) > > goto error_free_vers; > > Will it add a shared library to DT_NEEDED even if the IR symbol reference is > removed by LTO? Yes. That can't be helped. I know we worried about unnecessary --as-needed shared libraries in the past when IR symbols disappear after LTO, but I can't see a simple and reliable way for the linker to be correct. It's reasonably obvious that we need to load archive elements when they define IR referenced symbols, because the archive element might be an LTO object. What's not so obvious is whether loading of shared libraries should follow the same rule. I think they should, in order for LTO to get symbol resolution correct in corner cases. Basically LTO needs to know what shared libraries are loaded before recompilation. See commit a896df97b952 log comments. -- Alan Modra Australia Development Lab, IBM