public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
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

             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).