This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Fix BFD format matching for x86_64-w64-mingw32 -m32 LTO
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Sun, 14 Feb 2016 06:03:25 -0800
- Subject: Re: Fix BFD format matching for x86_64-w64-mingw32 -m32 LTO
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1602111610320 dot 29940 at digraph dot polyomino dot org dot uk>
On Thu, Feb 11, 2016 at 8:13 AM, Joseph Myers <joseph@codesourcery.com> wrote:
> In <https://sourceware.org/ml/binutils/2015-12/msg00190.html> (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 <joseph@codesourcery.com>
>
> * 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:
https://bugzilla.redhat.com/show_bug.cgi?id=1174065
I was wondering if it works for you.
--
H.J.
From 5dd9d477aa1f201d73e1fc932f3fdef8354baf62 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
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 @@
bfd/
+2015-02-08 H.J. Lu <hongjiu.lu@intel.com>
+
+ * 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 <hongjiu.lu@intel.com>
+
+ * format.c (bfd_check_format_matches): Don't check the plugin
+ target twice.
+
2012-06-04 H.J. Lu <hongjiu.lu@intel.com>
* 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"
+#if BFD_SUPPORTS_PLUGINS
+#include "plugin.h"
+#endif
/* 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)
continue;
+#if BFD_SUPPORTS_PLUGINS
+ /* 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;
+#endif
+
/* If we already tried a match, the bfd is modified and may
have sections attached, which will confuse the next
_bfd_check_format call. */
--
2.5.0