From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 476EE3840C3E for ; Sun, 21 Jun 2020 07:43:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 476EE3840C3E Received: by mail-pg1-x52e.google.com with SMTP id r18so6634617pgk.11 for ; Sun, 21 Jun 2020 00:43:35 -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:in-reply-to:user-agent; bh=j1tPCZkYD/6D8gQXTbPFpvW7HmIBEnp3dhUBZWZrOU4=; b=TEmUiChkVlneAYMhwCfJsF6gvJs/WEJ+hd2u6nKWlwole8dG6yRYVR6ktba4Ou/Dpc AaCXtadG9xBkckV+amGsaDXkA/DjBOXJ+vz+7BfZtJjx/Hn3PvDJmuhZVPhb/2Yg48D0 NQlD86dwKyhnMctt0UNFWbd4IK2B95pCVQy90zzNxq1CFPe6GrGs9bzchyVgNB10grku tD1zRk4+WRe/VvcjVghPpCoYoFMMjQ2+WyMZMNdSZleeWqrIa+eBJVnV00g2AL75BoQt DHVZr9z6Q6nHzaobXiZlpO0hZut/qCHL2pIgAkBooQLVfoLr6gCDv1SmvvDTSAhS3WBP 0j0g== X-Gm-Message-State: AOAM531tzf61e3MjP83VEyqmi9VuiJ3GNnP62x9Txd1yTZil3xNpj/C9 DhXofb67xA4QBOzJCRD/O7s= X-Google-Smtp-Source: ABdhPJwMA30k83fw41lpBL53mIG7/TfaYT51rIq0cRcj/eUQOK6pEBrEBvM+cuU9gxlfwzX9QfwYaA== X-Received: by 2002:a63:5f8c:: with SMTP id t134mr7771202pgb.99.1592725409419; Sun, 21 Jun 2020 00:43:29 -0700 (PDT) Received: from bubble.grove.modra.org ([2406:3400:51d:8cc0:10f7:401d:ba37:421c]) by smtp.gmail.com with ESMTPSA id n62sm3515947pjb.42.2020.06.21.00.43.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Jun 2020 00:43:28 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 4AF9C84E0D; Sun, 21 Jun 2020 17:13:24 +0930 (ACST) Date: Sun, 21 Jun 2020 17:13:24 +0930 From: Alan Modra To: Stephen Casner Cc: binutils@sourceware.org Subject: Re: Plugin tests in ld testsuite Message-ID: <20200621074323.GH21885@bubble.grove.modra.org> References: <20200529031340.GH5475@bubble.grove.modra.org> <20200616030543.GC12881@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, 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: Sun, 21 Jun 2020 07:43:36 -0000 On Sat, Jun 20, 2020 at 03:59:16PM -0700, Stephen Casner wrote: > On Tue, 16 Jun 2020, Alan Modra wrote: > > I think you would be pioneering AOUT plugin support if you chose to > > support plugins on pdp11. How much of a challenge do you enjoy? :-) > > My immediate goal is to avoid the unexpected failures for ld plugin > tests on the pdp11-aout target. Probably the simplest fix would be to > add a check near the top of ld/plugin.exp for pdp11-*-aout or *-*-aout > to skip the tests. However, it seems somewhat disingenuous for ld to > accept a -plugin option for the aout targets if the functionality is > broken, and removing it would allow the existing checks in plugin.exp > to skip the tests. > > I don't know what range of functionality can be provided by plugins. > Are there some uses other than claiming files and defining symbols > that may be functional for aout targets? gcc's link time optimization is the major reason we have plugins. > If removing the -plugin option is the right course of action, I'm not > sure how that should be done. I've looked at the configuration files > but I did not find any example of a target for which plugins are > disabled. It's also not clear where it would be reasonable to insert > a target-specific check. config/plugins.m4? config/largefile.m4? > Create a new variable to be set in ld/configure.tgt and checked in one > of the m4 files? > > Also, the disabling could be by just changing the default for the aout > targets to be --disable-plugins or it could be to remove the > configuration option completely if it does not make sense to allow > building with --enable-plugins. > > Alan, I noticed PR 26132 that you reported regarding problems in ar > for some targets with plugins enabled. I was hoping to see whether > the fix for that PR might show the direction for my questions above. I'm aiming to fix that PR by firstly making all files in ld/ that currently test ENABLE_PLUGINS instead test BFD_SUPPORTS_PLUGINS. That will allow just one configure file to control the default for whether plugins are enabled. I think it would be reasonable for some targets like pdp11 and alpha-vms to have plugins disabled by default, with users getting a warning if they override the default with --enable-plugins. -- Alan Modra Australia Development Lab, IBM