mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-27 14:39:09 +08:00
64bfc2584c
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. * 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.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.