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

[H.J. Lu]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Don-t-check-the-plugin-target-twice.patch
Type: text/x-patch
Size: 1893 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20160214/16d6bb46/attachment.bin>