This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix BFD format matching for x86_64-w64-mingw32 -m32 LTO

On Thu, Feb 11, 2016 at 8:13 AM, Joseph Myers <> wrote:
> In <> (commit
> 4a07dc81356ed8728e204e9aabeb256703c59aef), Kwok fixed a problem with
> the template used for a dummy BFD for an IR file for LTO on MinGW,
> where the input and output formats are not the same.
> A problem, however, remains in the case of linking for
> x86_64-w64-mingw32 -m32, where LTO linking reports an ambiguity
> between the pe-i386 and pei-i386 formats.  An object (pe-i386) with
> plugin data is being tested by the linker to see what formats match.
> The default format initially set by the linker when
> bfd_check_format_matches is called is pei-i386 (as that's the output
> format from the linker script), which does not match, so the function
> goes on to the loop over possible BFD vectors.  The pe-i386 vector
> matches, as it should.  One other vector matches: the plugin vector.
> bfd_check_format_matches tests a vector for matching by temporarily
> modifying the BFD object to use that vector then using
> _bfd_check_format on it.  So the BFD object is temporarily using
> plugin_vec.  _bfd_check_format ends up using bfd_plugin_object_p which
> uses plugin_object_p from ld which uses plugin_get_ir_dummy_bfd which
> succeeds, having created a BFD based on link_info.output_bfd (because
> srctemplate is the BFD temporarily using plugin_vec, even after Kwok's
> patch link_info.output_bfd is all that's available to base the dummy
> BFD on).  So we end up with a match from the plugin vector which uses
> the pei-i386 vector even though the pei-i386 vector itself does not
> match the input object.  (In the i686-mingw32 case, as opposed to this
> multilib case, pe-i386 is the default BFD target, which would
> short-circuit that logic.)
> There are two cases of the linker handling inputs with a plugin: they
> may be inputs that are also accepted by some non-plugin BFD format, as
> here, or they may be a format that would not be recognized at all, as
> with some tests in the ld testsuite.  In the former case, there is no
> need for BFD to accept the objects using the plugin vector, as the
> linker has its own logic to allow plugins to claim objects accepted by
> some other BFD vector.  Thus, this patch arranges for the plugin
> vector to have the lowest match priority, and for the priority from
> that vector to be used in the relevant case (the attempted match to
> the plugin vector results in TEMP pointing to the pei-i386 vector).
> Tested for GCC and Binutils testsuites for x86_64-pc-linux-gnu, as
> well as verifying that it fixes the observed LTO issue for
> x86_64-w64-mingw32.
> 2016-02-11  Joseph Myers  <>
>         * plugin.c (plugin_vec): Set match priority to 255.
>         * format.c (bfd_check_format_matches) [BFD_SUPPORTS_PLUGINS]: When
>         matching against the plugin vector, take priority from there not
>         from TEMP.

I have a related patch for:

I was wondering if it works for you.

From 5dd9d477aa1f201d73e1fc932f3fdef8354baf62 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <>
Date: Sun, 8 Feb 2015 17:53:24 -0800
Subject: [PATCH] Don't check the plugin target twice

If the plugin target is explicitly specified when a BFD file is opened,
don't check it twice.
 ChangeLog.lto-mixed | 11 +++++++++++
 bfd/format.c        | 10 ++++++++++
 2 files changed, 21 insertions(+)

diff --git a/ChangeLog.lto-mixed b/ChangeLog.lto-mixed
index 246511e..5088e37 100644
--- a/ChangeLog.lto-mixed
+++ b/ChangeLog.lto-mixed
@@ -1,5 +1,16 @@
+2015-02-08  H.J. Lu  <>
+	* format.c: Include "plugin.h"
+	(bfd_check_format_matches): Don't check the plugin target twice
+	if the plugin target is explicitly specified.
+2014-03-07  H.J. Lu  <>
+	* format.c (bfd_check_format_matches): Don't check the plugin
+	target twice.
 2012-06-04  H.J. Lu  <>
 	* plugin.c (add_symbols): Set tdata.plugin_data before calling
diff --git a/bfd/format.c b/bfd/format.c
index 97cbd22..11c3d9a 100644
--- a/bfd/format.c
+++ b/bfd/format.c
@@ -46,6 +46,9 @@ SUBSECTION
 #include "sysdep.h"
 #include "bfd.h"
 #include "libbfd.h"
+#include "plugin.h"
 /* IMPORT from targets.c.  */
 extern const size_t _bfd_target_vector_entries;
@@ -315,6 +318,13 @@ bfd_check_format_matches (bfd *abfd, bfd_format format, char ***matching)
 	  || (*target)->match_priority > best_match)
+      /* If the plugin target is explicitly specified when a BFD file
+	 is opened, don't check it twice.  */
+      if (bfd_plugin_specified_p () && bfd_plugin_target_p (*target))
+	continue;
       /* If we already tried a match, the bfd is modified and may
 	 have sections attached, which will confuse the next
 	 _bfd_check_format call.  */

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]