From: Alan Modra <amodra@gmail.com>
To: binutils@sourceware.org
Subject: ld -plugin options when plugins are disabled
Date: Wed, 3 Jun 2020 18:54:19 +0930 [thread overview]
Message-ID: <20200603092419.GI29024@bubble.grove.modra.org> (raw)
This patch makes ld accept and ignore -plugin options when configured
with --disable-plugins. The idea is to allow using a linker built
without plugin support with a gcc built with plugin support. Quite
obviously such a combination won't work if using LTO, but gcc has a
habit of passing a bunch of -plugin and -plugin-opt arguments to ld
even when not generating or linking LTO objects.
Why do I want to do this? Well, it lets me and other binutils
developers answer the question as to whether plugin support breaks
binutils in some areas, without recompiling gcc or arranging to
pass -fno-use-linker-plugin to gcc for testsuite runs.
Does anyone know of a project that tests for linker plugin support
by looking at ld -help output similarly to check_plugin_api_available
below? If so then the patch may need more tweaking.
* lexsup.c (ld_options): Accept -plugin and -plugin-opt when
!ENABLE_PLUGINS.
* testsuite/lib/ld-lib.exp (check_plugin_api_available): Adjust.
diff --git a/ld/lexsup.c b/ld/lexsup.c
index 412e2e6026..c651a1ccbe 100644
--- a/ld/lexsup.c
+++ b/ld/lexsup.c
@@ -185,6 +185,11 @@ static const struct ld_option ld_options[] =
{ {"flto-partition=", required_argument, NULL, OPTION_IGNORE},
'\0', NULL, N_("Ignored for GCC LTO option compatibility"),
ONE_DASH },
+#else
+ { {"plugin", required_argument, NULL, OPTION_IGNORE},
+ '\0', N_("PLUGIN"), N_("Load named plugin (ignored)"), ONE_DASH },
+ { {"plugin-opt", required_argument, NULL, OPTION_IGNORE},
+ '\0', N_("ARG"), N_("Send arg to last-loaded plugin (ignored)"), ONE_DASH },
#endif /* ENABLE_PLUGINS */
{ {"fuse-ld=", required_argument, NULL, OPTION_IGNORE},
'\0', NULL, N_("Ignored for GCC linker option compatibility"),
diff --git a/ld/testsuite/lib/ld-lib.exp b/ld/testsuite/lib/ld-lib.exp
index 015eda6eb9..6535881dd1 100644
--- a/ld/testsuite/lib/ld-lib.exp
+++ b/ld/testsuite/lib/ld-lib.exp
@@ -1135,7 +1135,8 @@ proc check_plugin_api_available { } {
if {![info exists plugin_api_available_saved]} {
# Check if the ld used by gcc supports --plugin.
set ld_output [remote_exec host $ld "--help"]
- if { [ string first "-plugin PLUGIN" $ld_output ] >= 0 } {
+ if { [regexp -- "-plugin PLUGIN \[^\n\r\]*" $ld_output line]
+ && ![regexp "ignored" $line] } {
set plugin_api_available_saved 1
} else {
set plugin_api_available_saved 0
--
Alan Modra
Australia Development Lab, IBM
next reply other threads:[~2020-06-03 9:24 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-03 9:24 Alan Modra [this message]
2020-06-06 5:09 ` Alan Modra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200603092419.GI29024@bubble.grove.modra.org \
--to=amodra@gmail.com \
--cc=binutils@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).