binutils-gdb/bfd/format.c

592 lines
17 KiB
C
Raw Normal View History

1999-05-03 09:29:11 +02:00
/* Generic BFD support for file formats.
Copyright (C) 1990-2019 Free Software Foundation, Inc.
1999-05-03 09:29:11 +02:00
Written by Cygnus Support.
This file is part of BFD, the Binary File Descriptor library.
1999-05-03 09:29:11 +02:00
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
1999-05-03 09:29:11 +02:00
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
1999-05-03 09:29:11 +02:00
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
MA 02110-1301, USA. */
1999-05-03 09:29:11 +02:00
/*
SECTION
File formats
A format is a BFD concept of high level file contents type. The
formats supported by BFD are:
1999-05-03 09:29:11 +02:00
o <<bfd_object>>
The BFD may contain data, symbols, relocations and debug info.
o <<bfd_archive>>
The BFD contains other BFDs and an optional index.
o <<bfd_core>>
The BFD contains the result of an executable core dump.
SUBSECTION
File format functions
1999-05-03 09:29:11 +02:00
*/
#include "sysdep.h"
#include "bfd.h"
1999-05-03 09:29:11 +02:00
#include "libbfd.h"
/* IMPORT from targets.c. */
extern const size_t _bfd_target_vector_entries;
/*
FUNCTION
bfd_check_format
SYNOPSIS
bfd_boolean bfd_check_format (bfd *abfd, bfd_format format);
1999-05-03 09:29:11 +02:00
DESCRIPTION
Verify if the file attached to the BFD @var{abfd} is compatible
with the format @var{format} (i.e., one of <<bfd_object>>,
<<bfd_archive>> or <<bfd_core>>).
If the BFD has been set to a specific target before the
call, only the named target and format combination is
checked. If the target has not been set, or has been set to
<<default>>, then all the known target backends is
interrogated to determine a match. If the default target
matches, it is used. If not, exactly one target must recognize
the file, or an error results.
The function returns <<TRUE>> on success, otherwise <<FALSE>>
with one of the following error codes:
1999-05-03 09:29:11 +02:00
o <<bfd_error_invalid_operation>> -
if <<format>> is not one of <<bfd_object>>, <<bfd_archive>> or
<<bfd_core>>.
o <<bfd_error_system_call>> -
if an error occured during a read - even some file mismatches
can cause bfd_error_system_calls.
o <<file_not_recognised>> -
none of the backends recognised the file format.
o <<bfd_error_file_ambiguously_recognized>> -
more than one backend recognised the file format.
*/
bfd_boolean
2003-06-29 12:06:40 +02:00
bfd_check_format (bfd *abfd, bfd_format format)
1999-05-03 09:29:11 +02:00
{
return bfd_check_format_matches (abfd, format, NULL);
}
struct bfd_preserve
{
void *marker;
void *tdata;
flagword flags;
const struct bfd_arch_info *arch_info;
struct bfd_section *sections;
struct bfd_section *section_last;
unsigned int section_count;
PR22458, failure to choose a matching ELF target https://sourceware.org/ml/binutils/2013-05/msg00271.html was supposed to banish "file format is ambiguous" errors for ELF. It didn't, because the code supposedly detecting formats that implement match_priority didn't work. That was due to not placing all matching targets into the vector of matching targets. ELF objects should all match the generic ELF target (priority 2), plus one or more machine specific targets (priority 1), and perhaps a single machine specific target with OS/ABI set (priority 0, best match). So the armel object in the testcase actually matches elf32-littlearm, elf32-littlearm-symbian, and elf32-littlearm-vxworks (all priority 1), and elf32-little (priority 2). As the PR reported, elf32-little wasn't seen as matching. Fixing that part of the problem wasn't too difficult but matching the generic ELF target as well as the ARM ELF targets resulted in ARM testsuite failures. These proved to be the annoying reordering of stubs that occurs from time to time due to the stub names containing the section id. Matching another target causes more sections to be created in elf_object_p. If section ids change, stub names change, which results in different hashing and can therefore result in different hash table traversal and stub creation order. That particular problem is fixed by resetting section_id to the initial state before attempting each target match, and taking a snapshot of its value after a successful match. PR 22458 * format.c (struct bfd_preserve): Add section_id. (bfd_preserve_save, bfd_preserve_restore): Save and restore _bfd_section_id. (bfd_reinit): Set _bfd_section_id. (bfd_check_format_matches): Put all matches of any priority into matching_vector. Save initial section id and start each attempted match at that section id. * libbfd-in.h (_bfd_section_id): Declare. * section.c (_bfd_section_id): Rename from section_id and make global. Adjust uses. (bfd_get_next_section_id): Delete. * elf64-ppc.c (ppc64_elf_setup_section_lists): Replace use of bfd_get_section_id with _bfd_section_id. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate.
2018-05-16 04:03:48 +02:00
unsigned int section_id;
struct bfd_hash_table section_htab;
const struct bfd_build_id *build_id;
};
/* When testing an object for compatibility with a particular target
back-end, the back-end object_p function needs to set up certain
fields in the bfd on successfully recognizing the object. This
typically happens in a piecemeal fashion, with failures possible at
many points. On failure, the bfd is supposed to be restored to its
initial state, which is virtually impossible. However, restoring a
subset of the bfd state works in practice. This function stores
the subset. */
static bfd_boolean
bfd_preserve_save (bfd *abfd, struct bfd_preserve *preserve)
{
preserve->tdata = abfd->tdata.any;
preserve->arch_info = abfd->arch_info;
preserve->flags = abfd->flags;
preserve->sections = abfd->sections;
preserve->section_last = abfd->section_last;
preserve->section_count = abfd->section_count;
PR22458, failure to choose a matching ELF target https://sourceware.org/ml/binutils/2013-05/msg00271.html was supposed to banish "file format is ambiguous" errors for ELF. It didn't, because the code supposedly detecting formats that implement match_priority didn't work. That was due to not placing all matching targets into the vector of matching targets. ELF objects should all match the generic ELF target (priority 2), plus one or more machine specific targets (priority 1), and perhaps a single machine specific target with OS/ABI set (priority 0, best match). So the armel object in the testcase actually matches elf32-littlearm, elf32-littlearm-symbian, and elf32-littlearm-vxworks (all priority 1), and elf32-little (priority 2). As the PR reported, elf32-little wasn't seen as matching. Fixing that part of the problem wasn't too difficult but matching the generic ELF target as well as the ARM ELF targets resulted in ARM testsuite failures. These proved to be the annoying reordering of stubs that occurs from time to time due to the stub names containing the section id. Matching another target causes more sections to be created in elf_object_p. If section ids change, stub names change, which results in different hashing and can therefore result in different hash table traversal and stub creation order. That particular problem is fixed by resetting section_id to the initial state before attempting each target match, and taking a snapshot of its value after a successful match. PR 22458 * format.c (struct bfd_preserve): Add section_id. (bfd_preserve_save, bfd_preserve_restore): Save and restore _bfd_section_id. (bfd_reinit): Set _bfd_section_id. (bfd_check_format_matches): Put all matches of any priority into matching_vector. Save initial section id and start each attempted match at that section id. * libbfd-in.h (_bfd_section_id): Declare. * section.c (_bfd_section_id): Rename from section_id and make global. Adjust uses. (bfd_get_next_section_id): Delete. * elf64-ppc.c (ppc64_elf_setup_section_lists): Replace use of bfd_get_section_id with _bfd_section_id. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate.
2018-05-16 04:03:48 +02:00
preserve->section_id = _bfd_section_id;
preserve->section_htab = abfd->section_htab;
preserve->marker = bfd_alloc (abfd, 1);
preserve->build_id = abfd->build_id;
if (preserve->marker == NULL)
return FALSE;
return bfd_hash_table_init (&abfd->section_htab, bfd_section_hash_newfunc,
sizeof (struct section_hash_entry));
}
/* Clear out a subset of BFD state. */
static void
PR22458, failure to choose a matching ELF target https://sourceware.org/ml/binutils/2013-05/msg00271.html was supposed to banish "file format is ambiguous" errors for ELF. It didn't, because the code supposedly detecting formats that implement match_priority didn't work. That was due to not placing all matching targets into the vector of matching targets. ELF objects should all match the generic ELF target (priority 2), plus one or more machine specific targets (priority 1), and perhaps a single machine specific target with OS/ABI set (priority 0, best match). So the armel object in the testcase actually matches elf32-littlearm, elf32-littlearm-symbian, and elf32-littlearm-vxworks (all priority 1), and elf32-little (priority 2). As the PR reported, elf32-little wasn't seen as matching. Fixing that part of the problem wasn't too difficult but matching the generic ELF target as well as the ARM ELF targets resulted in ARM testsuite failures. These proved to be the annoying reordering of stubs that occurs from time to time due to the stub names containing the section id. Matching another target causes more sections to be created in elf_object_p. If section ids change, stub names change, which results in different hashing and can therefore result in different hash table traversal and stub creation order. That particular problem is fixed by resetting section_id to the initial state before attempting each target match, and taking a snapshot of its value after a successful match. PR 22458 * format.c (struct bfd_preserve): Add section_id. (bfd_preserve_save, bfd_preserve_restore): Save and restore _bfd_section_id. (bfd_reinit): Set _bfd_section_id. (bfd_check_format_matches): Put all matches of any priority into matching_vector. Save initial section id and start each attempted match at that section id. * libbfd-in.h (_bfd_section_id): Declare. * section.c (_bfd_section_id): Rename from section_id and make global. Adjust uses. (bfd_get_next_section_id): Delete. * elf64-ppc.c (ppc64_elf_setup_section_lists): Replace use of bfd_get_section_id with _bfd_section_id. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate.
2018-05-16 04:03:48 +02:00
bfd_reinit (bfd *abfd, unsigned int section_id)
{
abfd->tdata.any = NULL;
abfd->arch_info = &bfd_default_arch_struct;
abfd->flags &= BFD_FLAGS_SAVED;
bfd_section_list_clear (abfd);
PR22458, failure to choose a matching ELF target https://sourceware.org/ml/binutils/2013-05/msg00271.html was supposed to banish "file format is ambiguous" errors for ELF. It didn't, because the code supposedly detecting formats that implement match_priority didn't work. That was due to not placing all matching targets into the vector of matching targets. ELF objects should all match the generic ELF target (priority 2), plus one or more machine specific targets (priority 1), and perhaps a single machine specific target with OS/ABI set (priority 0, best match). So the armel object in the testcase actually matches elf32-littlearm, elf32-littlearm-symbian, and elf32-littlearm-vxworks (all priority 1), and elf32-little (priority 2). As the PR reported, elf32-little wasn't seen as matching. Fixing that part of the problem wasn't too difficult but matching the generic ELF target as well as the ARM ELF targets resulted in ARM testsuite failures. These proved to be the annoying reordering of stubs that occurs from time to time due to the stub names containing the section id. Matching another target causes more sections to be created in elf_object_p. If section ids change, stub names change, which results in different hashing and can therefore result in different hash table traversal and stub creation order. That particular problem is fixed by resetting section_id to the initial state before attempting each target match, and taking a snapshot of its value after a successful match. PR 22458 * format.c (struct bfd_preserve): Add section_id. (bfd_preserve_save, bfd_preserve_restore): Save and restore _bfd_section_id. (bfd_reinit): Set _bfd_section_id. (bfd_check_format_matches): Put all matches of any priority into matching_vector. Save initial section id and start each attempted match at that section id. * libbfd-in.h (_bfd_section_id): Declare. * section.c (_bfd_section_id): Rename from section_id and make global. Adjust uses. (bfd_get_next_section_id): Delete. * elf64-ppc.c (ppc64_elf_setup_section_lists): Replace use of bfd_get_section_id with _bfd_section_id. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate.
2018-05-16 04:03:48 +02:00
_bfd_section_id = section_id;
}
/* Restores bfd state saved by bfd_preserve_save. */
static void
bfd_preserve_restore (bfd *abfd, struct bfd_preserve *preserve)
{
bfd_hash_table_free (&abfd->section_htab);
abfd->tdata.any = preserve->tdata;
abfd->arch_info = preserve->arch_info;
abfd->flags = preserve->flags;
abfd->section_htab = preserve->section_htab;
abfd->sections = preserve->sections;
abfd->section_last = preserve->section_last;
abfd->section_count = preserve->section_count;
PR22458, failure to choose a matching ELF target https://sourceware.org/ml/binutils/2013-05/msg00271.html was supposed to banish "file format is ambiguous" errors for ELF. It didn't, because the code supposedly detecting formats that implement match_priority didn't work. That was due to not placing all matching targets into the vector of matching targets. ELF objects should all match the generic ELF target (priority 2), plus one or more machine specific targets (priority 1), and perhaps a single machine specific target with OS/ABI set (priority 0, best match). So the armel object in the testcase actually matches elf32-littlearm, elf32-littlearm-symbian, and elf32-littlearm-vxworks (all priority 1), and elf32-little (priority 2). As the PR reported, elf32-little wasn't seen as matching. Fixing that part of the problem wasn't too difficult but matching the generic ELF target as well as the ARM ELF targets resulted in ARM testsuite failures. These proved to be the annoying reordering of stubs that occurs from time to time due to the stub names containing the section id. Matching another target causes more sections to be created in elf_object_p. If section ids change, stub names change, which results in different hashing and can therefore result in different hash table traversal and stub creation order. That particular problem is fixed by resetting section_id to the initial state before attempting each target match, and taking a snapshot of its value after a successful match. PR 22458 * format.c (struct bfd_preserve): Add section_id. (bfd_preserve_save, bfd_preserve_restore): Save and restore _bfd_section_id. (bfd_reinit): Set _bfd_section_id. (bfd_check_format_matches): Put all matches of any priority into matching_vector. Save initial section id and start each attempted match at that section id. * libbfd-in.h (_bfd_section_id): Declare. * section.c (_bfd_section_id): Rename from section_id and make global. Adjust uses. (bfd_get_next_section_id): Delete. * elf64-ppc.c (ppc64_elf_setup_section_lists): Replace use of bfd_get_section_id with _bfd_section_id. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate.
2018-05-16 04:03:48 +02:00
_bfd_section_id = preserve->section_id;
abfd->build_id = preserve->build_id;
/* bfd_release frees all memory more recently bfd_alloc'd than
its arg, as well as its arg. */
bfd_release (abfd, preserve->marker);
preserve->marker = NULL;
}
/* Called when the bfd state saved by bfd_preserve_save is no longer
needed. */
static void
bfd_preserve_finish (bfd *abfd ATTRIBUTE_UNUSED, struct bfd_preserve *preserve)
{
/* It would be nice to be able to free more memory here, eg. old
tdata, but that's not possible since these blocks are sitting
inside bfd_alloc'd memory. The section hash is on a separate
objalloc. */
bfd_hash_table_free (&preserve->section_htab);
preserve->marker = NULL;
}
1999-05-03 09:29:11 +02:00
/*
FUNCTION
bfd_check_format_matches
SYNOPSIS
2003-06-29 12:06:40 +02:00
bfd_boolean bfd_check_format_matches
(bfd *abfd, bfd_format format, char ***matching);
1999-05-03 09:29:11 +02:00
DESCRIPTION
Like <<bfd_check_format>>, except when it returns FALSE with
1999-05-03 09:29:11 +02:00
<<bfd_errno>> set to <<bfd_error_file_ambiguously_recognized>>. In that
case, if @var{matching} is not NULL, it will be filled in with
a NULL-terminated list of the names of the formats that matched,
allocated with <<malloc>>.
Then the user may choose a format and try again.
When done with the list that @var{matching} points to, the caller
should free it.
1999-05-03 09:29:11 +02:00
*/
bfd_boolean
2003-06-29 12:06:40 +02:00
bfd_check_format_matches (bfd *abfd, bfd_format format, char ***matching)
1999-05-03 09:29:11 +02:00
{
extern const bfd_target binary_vec;
Fix BFD format matching for x86_64-w64-mingw32 -m32 LTO. 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.
2016-02-16 01:27:11 +01:00
#if BFD_SUPPORTS_PLUGINS
extern const bfd_target plugin_vec;
#endif
const bfd_target * const *target;
const bfd_target **matching_vector = NULL;
const bfd_target *save_targ, *right_targ, *ar_right_targ, *match_targ;
int match_count, best_count, best_match;
int ar_match_index;
PR22458, failure to choose a matching ELF target https://sourceware.org/ml/binutils/2013-05/msg00271.html was supposed to banish "file format is ambiguous" errors for ELF. It didn't, because the code supposedly detecting formats that implement match_priority didn't work. That was due to not placing all matching targets into the vector of matching targets. ELF objects should all match the generic ELF target (priority 2), plus one or more machine specific targets (priority 1), and perhaps a single machine specific target with OS/ABI set (priority 0, best match). So the armel object in the testcase actually matches elf32-littlearm, elf32-littlearm-symbian, and elf32-littlearm-vxworks (all priority 1), and elf32-little (priority 2). As the PR reported, elf32-little wasn't seen as matching. Fixing that part of the problem wasn't too difficult but matching the generic ELF target as well as the ARM ELF targets resulted in ARM testsuite failures. These proved to be the annoying reordering of stubs that occurs from time to time due to the stub names containing the section id. Matching another target causes more sections to be created in elf_object_p. If section ids change, stub names change, which results in different hashing and can therefore result in different hash table traversal and stub creation order. That particular problem is fixed by resetting section_id to the initial state before attempting each target match, and taking a snapshot of its value after a successful match. PR 22458 * format.c (struct bfd_preserve): Add section_id. (bfd_preserve_save, bfd_preserve_restore): Save and restore _bfd_section_id. (bfd_reinit): Set _bfd_section_id. (bfd_check_format_matches): Put all matches of any priority into matching_vector. Save initial section id and start each attempted match at that section id. * libbfd-in.h (_bfd_section_id): Declare. * section.c (_bfd_section_id): Rename from section_id and make global. Adjust uses. (bfd_get_next_section_id): Delete. * elf64-ppc.c (ppc64_elf_setup_section_lists): Replace use of bfd_get_section_id with _bfd_section_id. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate.
2018-05-16 04:03:48 +02:00
unsigned int initial_section_id = _bfd_section_id;
struct bfd_preserve preserve;
1999-05-03 09:29:11 +02:00
if (matching != NULL)
*matching = NULL;
if (!bfd_read_p (abfd)
|| (unsigned int) abfd->format >= (unsigned int) bfd_type_end)
2000-07-20 02:31:39 +02:00
{
bfd_set_error (bfd_error_invalid_operation);
return FALSE;
2000-07-20 02:31:39 +02:00
}
1999-05-03 09:29:11 +02:00
if (abfd->format != bfd_unknown)
return abfd->format == format;
1999-05-03 09:29:11 +02:00
if (matching != NULL || *bfd_associated_vector != NULL)
1999-05-03 09:29:11 +02:00
{
bfd_size_type amt;
amt = sizeof (*matching_vector) * 2 * _bfd_target_vector_entries;
Updated soruces in bfd/* to compile cleanly with -Wc++-compat. * bfd/aoutx.h: Add casts. * bfd/archive.c: Add casts. * bfd/archive64.c: Add casts. * bfd/archures.c: Add casts. * bfd/bfd-in2.h: Regenerated. * bfd/bfd.c: Add casts. (enum bfd_direction): Move out to top level. * bfd/bfdio.c: Add casts. * bfd/binary.c: Add casts. * bfd/cache.c (cache_bseek,cache_bread_1,cache_bwrite): Updated parameter to use enum value instead of int. * bfd/coffcode.h: Add casts. * bfd/coffgen.c: Add casts. * bfd/cofflink.c: Add casts. * bfd/compress.c: Add casts. * bfd/dwarf1.c: Add casts. * bfd/dwarf2.c: Add casts. (struct dwarf2_debug): Rename member bfd to bfd_ptr. Update code to use new name. * bfd/elf-attrs.c: Add casts. * bfd/elf-bfd.h (elf_link_virtual_table_entry): Gives name to anonymous struct. (union gotplt_union, struct elf_link_virtual_table_entry): Move to top level. * bfd/elf-eh-frame.c: Add casts. * bfd/elf-strtab.c: Add casts. * bfd/elf.c: Add casts. (_bfd_elm_make_Section_from_phdr): Change argument name from typename to type_name. * bfd/elf32-i386.c: Add casts. * bfd/elf64-x86-64.c: Add casts. * bfd/elfcode.h: Add casts. * bfd/elfcore.h: Add casts. * bfd/elflink.c: Add casts. * bfd/format.c: Add casts. * bfd/hash.c: Add casts. * bfd/ihex.c: Add casts. * bfd/libaout.h (enum aout_subformat, enum aout_magic): Move to top level. * bfd/libbfd.c: Add casts. * bfd/linker.c: Add casts. * bfd/merge.c: Add casts. * bfd/opncls.c: Add casts. * bfd/peXXigen.c: Add casts. * bfd/peicode.h: Add casts. * bfd/reloc.c: Add casts. * bfd/section.c: Add casts. * bfd/simple.c: Add casts. * bfd/srec.c: Add casts. * bfd/stabs.c: Add casts. * bfd/syms.c: Add casts. * bfd/targets.c: Add casts. * bfd/tekhex.c: Add casts. * bfd/verilog.c: Add casts. * include/bfdlink.h (struct bfd_link_hash_common_entry): Move to top level.
2009-09-09 23:38:59 +02:00
matching_vector = (const bfd_target **) bfd_malloc (amt);
1999-05-03 09:29:11 +02:00
if (!matching_vector)
return FALSE;
1999-05-03 09:29:11 +02:00
}
2000-07-20 02:31:39 +02:00
/* Presume the answer is yes. */
1999-05-03 09:29:11 +02:00
abfd->format = format;
save_targ = abfd->xvec;
preserve.marker = NULL;
1999-05-03 09:29:11 +02:00
/* If the target type was explicitly specified, just check that target. */
2000-07-20 02:31:39 +02:00
if (!abfd->target_defaulted)
{
if (bfd_seek (abfd, (file_ptr) 0, SEEK_SET) != 0) /* rewind! */
goto err_ret;
2000-07-20 02:31:39 +02:00
right_targ = BFD_SEND_FMT (abfd, _bfd_check_format, (abfd));
2000-07-20 02:31:39 +02:00
if (right_targ)
goto ok_ret;
2000-07-20 02:31:39 +02:00
/* For a long time the code has dropped through to check all
targets if the specified target was wrong. I don't know why,
and I'm reluctant to change it. However, in the case of an
archive, it can cause problems. If the specified target does
not permit archives (e.g., the binary target), then we should
not allow some other target to recognize it as an archive, but
should instead allow the specified target to recognize it as an
object. When I first made this change, it broke the PE target,
because the specified pei-i386 target did not recognize the
actual pe-i386 archive. Since there may be other problems of
this sort, I changed this test to check only for the binary
target. */
if (format == bfd_archive && save_targ == &binary_vec)
goto err_unrecog;
2000-07-20 02:31:39 +02:00
}
/* Since the target type was defaulted, check them all in the hope
that one will be uniquely recognized. */
right_targ = NULL;
ar_right_targ = NULL;
match_targ = NULL;
best_match = 256;
best_count = 0;
match_count = 0;
ar_match_index = _bfd_target_vector_entries;
2000-07-20 02:31:39 +02:00
for (target = bfd_target_vector; *target != NULL; target++)
{
const bfd_target *temp;
/* The binary target matches anything, so don't return it when
searching. Don't match the plugin target if we have another
alternative since we want to properly set the input format
before allowing a plugin to claim the file. Also, don't
check the default target twice. */
if (*target == &binary_vec
#if BFD_SUPPORTS_PLUGINS
|| (match_count != 0 && *target == &plugin_vec)
#endif
PR22458, failure to choose a matching ELF target https://sourceware.org/ml/binutils/2013-05/msg00271.html was supposed to banish "file format is ambiguous" errors for ELF. It didn't, because the code supposedly detecting formats that implement match_priority didn't work. That was due to not placing all matching targets into the vector of matching targets. ELF objects should all match the generic ELF target (priority 2), plus one or more machine specific targets (priority 1), and perhaps a single machine specific target with OS/ABI set (priority 0, best match). So the armel object in the testcase actually matches elf32-littlearm, elf32-littlearm-symbian, and elf32-littlearm-vxworks (all priority 1), and elf32-little (priority 2). As the PR reported, elf32-little wasn't seen as matching. Fixing that part of the problem wasn't too difficult but matching the generic ELF target as well as the ARM ELF targets resulted in ARM testsuite failures. These proved to be the annoying reordering of stubs that occurs from time to time due to the stub names containing the section id. Matching another target causes more sections to be created in elf_object_p. If section ids change, stub names change, which results in different hashing and can therefore result in different hash table traversal and stub creation order. That particular problem is fixed by resetting section_id to the initial state before attempting each target match, and taking a snapshot of its value after a successful match. PR 22458 * format.c (struct bfd_preserve): Add section_id. (bfd_preserve_save, bfd_preserve_restore): Save and restore _bfd_section_id. (bfd_reinit): Set _bfd_section_id. (bfd_check_format_matches): Put all matches of any priority into matching_vector. Save initial section id and start each attempted match at that section id. * libbfd-in.h (_bfd_section_id): Declare. * section.c (_bfd_section_id): Rename from section_id and make global. Adjust uses. (bfd_get_next_section_id): Delete. * elf64-ppc.c (ppc64_elf_setup_section_lists): Replace use of bfd_get_section_id with _bfd_section_id. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate.
2018-05-16 04:03:48 +02:00
|| (!abfd->target_defaulted && *target == save_targ))
2000-07-20 02:31:39 +02:00
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. */
PR22458, failure to choose a matching ELF target https://sourceware.org/ml/binutils/2013-05/msg00271.html was supposed to banish "file format is ambiguous" errors for ELF. It didn't, because the code supposedly detecting formats that implement match_priority didn't work. That was due to not placing all matching targets into the vector of matching targets. ELF objects should all match the generic ELF target (priority 2), plus one or more machine specific targets (priority 1), and perhaps a single machine specific target with OS/ABI set (priority 0, best match). So the armel object in the testcase actually matches elf32-littlearm, elf32-littlearm-symbian, and elf32-littlearm-vxworks (all priority 1), and elf32-little (priority 2). As the PR reported, elf32-little wasn't seen as matching. Fixing that part of the problem wasn't too difficult but matching the generic ELF target as well as the ARM ELF targets resulted in ARM testsuite failures. These proved to be the annoying reordering of stubs that occurs from time to time due to the stub names containing the section id. Matching another target causes more sections to be created in elf_object_p. If section ids change, stub names change, which results in different hashing and can therefore result in different hash table traversal and stub creation order. That particular problem is fixed by resetting section_id to the initial state before attempting each target match, and taking a snapshot of its value after a successful match. PR 22458 * format.c (struct bfd_preserve): Add section_id. (bfd_preserve_save, bfd_preserve_restore): Save and restore _bfd_section_id. (bfd_reinit): Set _bfd_section_id. (bfd_check_format_matches): Put all matches of any priority into matching_vector. Save initial section id and start each attempted match at that section id. * libbfd-in.h (_bfd_section_id): Declare. * section.c (_bfd_section_id): Rename from section_id and make global. Adjust uses. (bfd_get_next_section_id): Delete. * elf64-ppc.c (ppc64_elf_setup_section_lists): Replace use of bfd_get_section_id with _bfd_section_id. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate.
2018-05-16 04:03:48 +02:00
bfd_reinit (abfd, initial_section_id);
/* Change BFD's target temporarily. */
abfd->xvec = *target;
if (bfd_seek (abfd, (file_ptr) 0, SEEK_SET) != 0)
goto err_ret;
2000-07-20 02:31:39 +02:00
/* If _bfd_check_format neglects to set bfd_error, assume
bfd_error_wrong_format. We didn't used to even pay any
attention to bfd_error, so I suspect that some
_bfd_check_format might have this problem. */
bfd_set_error (bfd_error_wrong_format);
temp = BFD_SEND_FMT (abfd, _bfd_check_format, (abfd));
if (temp)
{
Fix BFD format matching for x86_64-w64-mingw32 -m32 LTO. 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.
2016-02-16 01:27:11 +01:00
int match_priority = temp->match_priority;
#if BFD_SUPPORTS_PLUGINS
/* If this object can be handled by a plugin, give that the
lowest priority; objects both handled by a plugin and
with an underlying object format will be claimed
separately by the plugin. */
if (*target == &plugin_vec)
match_priority = (*target)->match_priority;
#endif
match_targ = temp;
if (preserve.marker != NULL)
bfd_preserve_finish (abfd, &preserve);
if (abfd->format != bfd_archive
|| (bfd_has_map (abfd)
&& bfd_get_error () != bfd_error_wrong_object_format))
{
/* If this is the default target, accept it, even if
other targets might match. People who want those
other targets have to set the GNUTARGET variable. */
if (temp == bfd_default_vector[0])
goto ok_ret;
if (matching_vector)
matching_vector[match_count] = temp;
match_count++;
Fix BFD format matching for x86_64-w64-mingw32 -m32 LTO. 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.
2016-02-16 01:27:11 +01:00
if (match_priority < best_match)
{
Fix BFD format matching for x86_64-w64-mingw32 -m32 LTO. 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.
2016-02-16 01:27:11 +01:00
best_match = match_priority;
best_count = 0;
}
PR22458, failure to choose a matching ELF target https://sourceware.org/ml/binutils/2013-05/msg00271.html was supposed to banish "file format is ambiguous" errors for ELF. It didn't, because the code supposedly detecting formats that implement match_priority didn't work. That was due to not placing all matching targets into the vector of matching targets. ELF objects should all match the generic ELF target (priority 2), plus one or more machine specific targets (priority 1), and perhaps a single machine specific target with OS/ABI set (priority 0, best match). So the armel object in the testcase actually matches elf32-littlearm, elf32-littlearm-symbian, and elf32-littlearm-vxworks (all priority 1), and elf32-little (priority 2). As the PR reported, elf32-little wasn't seen as matching. Fixing that part of the problem wasn't too difficult but matching the generic ELF target as well as the ARM ELF targets resulted in ARM testsuite failures. These proved to be the annoying reordering of stubs that occurs from time to time due to the stub names containing the section id. Matching another target causes more sections to be created in elf_object_p. If section ids change, stub names change, which results in different hashing and can therefore result in different hash table traversal and stub creation order. That particular problem is fixed by resetting section_id to the initial state before attempting each target match, and taking a snapshot of its value after a successful match. PR 22458 * format.c (struct bfd_preserve): Add section_id. (bfd_preserve_save, bfd_preserve_restore): Save and restore _bfd_section_id. (bfd_reinit): Set _bfd_section_id. (bfd_check_format_matches): Put all matches of any priority into matching_vector. Save initial section id and start each attempted match at that section id. * libbfd-in.h (_bfd_section_id): Declare. * section.c (_bfd_section_id): Rename from section_id and make global. Adjust uses. (bfd_get_next_section_id): Delete. * elf64-ppc.c (ppc64_elf_setup_section_lists): Replace use of bfd_get_section_id with _bfd_section_id. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate.
2018-05-16 04:03:48 +02:00
if (match_priority <= best_match)
{
/* This format checks out as ok! */
right_targ = temp;
best_count++;
}
}
else
{
/* An archive with no armap or objects of the wrong
type. We want this target to match if we get no
better matches. */
if (ar_right_targ != bfd_default_vector[0])
ar_right_targ = *target;
if (matching_vector)
matching_vector[ar_match_index] = *target;
ar_match_index++;
}
if (!bfd_preserve_save (abfd, &preserve))
goto err_ret;
}
else if (bfd_get_error () != bfd_error_wrong_format)
goto err_ret;
2000-07-20 02:31:39 +02:00
}
if (best_count == 1)
match_count = 1;
if (match_count == 0)
{
/* Try partial matches. */
right_targ = ar_right_targ;
if (right_targ == bfd_default_vector[0])
{
match_count = 1;
}
else
{
match_count = ar_match_index - _bfd_target_vector_entries;
if (matching_vector && match_count > 1)
memcpy (matching_vector,
matching_vector + _bfd_target_vector_entries,
sizeof (*matching_vector) * match_count);
}
}
/* We have more than one equally good match. If any of the best
matches is a target in config.bfd targ_defvec or targ_selvecs,
choose it. */
if (match_count > 1)
{
const bfd_target * const *assoc = bfd_associated_vector;
while ((right_targ = *assoc++) != NULL)
{
int i = match_count;
while (--i >= 0)
if (matching_vector[i] == right_targ
&& right_targ->match_priority <= best_match)
break;
if (i >= 0)
{
match_count = 1;
break;
}
}
}
/* We still have more than one equally good match, and at least some
of the targets support match priority. Choose the first of the
best matches. */
if (matching_vector && match_count > 1 && best_count != match_count)
{
int i;
for (i = 0; i < match_count; i++)
{
right_targ = matching_vector[i];
if (right_targ->match_priority <= best_match)
break;
}
match_count = 1;
}
/* There is way too much undoing of half-known state here. We
really shouldn't iterate on live bfd's. Note that saving the
whole bfd and restoring it would be even worse; the first thing
you notice is that the cached bfd file position gets out of sync. */
if (preserve.marker != NULL)
bfd_preserve_restore (abfd, &preserve);
2000-07-20 02:31:39 +02:00
if (match_count == 1)
{
abfd->xvec = right_targ;
/* If we come out of the loop knowing that the last target that
matched is the one we want, then ABFD should still be in a usable
state (except possibly for XVEC). */
if (match_targ != right_targ)
{
PR22458, failure to choose a matching ELF target https://sourceware.org/ml/binutils/2013-05/msg00271.html was supposed to banish "file format is ambiguous" errors for ELF. It didn't, because the code supposedly detecting formats that implement match_priority didn't work. That was due to not placing all matching targets into the vector of matching targets. ELF objects should all match the generic ELF target (priority 2), plus one or more machine specific targets (priority 1), and perhaps a single machine specific target with OS/ABI set (priority 0, best match). So the armel object in the testcase actually matches elf32-littlearm, elf32-littlearm-symbian, and elf32-littlearm-vxworks (all priority 1), and elf32-little (priority 2). As the PR reported, elf32-little wasn't seen as matching. Fixing that part of the problem wasn't too difficult but matching the generic ELF target as well as the ARM ELF targets resulted in ARM testsuite failures. These proved to be the annoying reordering of stubs that occurs from time to time due to the stub names containing the section id. Matching another target causes more sections to be created in elf_object_p. If section ids change, stub names change, which results in different hashing and can therefore result in different hash table traversal and stub creation order. That particular problem is fixed by resetting section_id to the initial state before attempting each target match, and taking a snapshot of its value after a successful match. PR 22458 * format.c (struct bfd_preserve): Add section_id. (bfd_preserve_save, bfd_preserve_restore): Save and restore _bfd_section_id. (bfd_reinit): Set _bfd_section_id. (bfd_check_format_matches): Put all matches of any priority into matching_vector. Save initial section id and start each attempted match at that section id. * libbfd-in.h (_bfd_section_id): Declare. * section.c (_bfd_section_id): Rename from section_id and make global. Adjust uses. (bfd_get_next_section_id): Delete. * elf64-ppc.c (ppc64_elf_setup_section_lists): Replace use of bfd_get_section_id with _bfd_section_id. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate.
2018-05-16 04:03:48 +02:00
bfd_reinit (abfd, initial_section_id);
if (bfd_seek (abfd, (file_ptr) 0, SEEK_SET) != 0)
goto err_ret;
match_targ = BFD_SEND_FMT (abfd, _bfd_check_format, (abfd));
BFD_ASSERT (match_targ != NULL);
}
ok_ret:
/* If the file was opened for update, then `output_has_begun'
some time ago when the file was created. Do not recompute
sections sizes or alignments in _bfd_set_section_contents.
We can not set this flag until after checking the format,
because it will interfere with creation of BFD sections. */
if (abfd->direction == both_direction)
abfd->output_has_begun = TRUE;
if (matching_vector)
free (matching_vector);
/* File position has moved, BTW. */
return TRUE;
1999-05-03 09:29:11 +02:00
}
if (match_count == 0)
{
err_unrecog:
1999-05-03 09:29:11 +02:00
bfd_set_error (bfd_error_file_not_recognized);
err_ret:
abfd->xvec = save_targ;
abfd->format = bfd_unknown;
if (matching_vector)
2003-06-29 12:06:40 +02:00
free (matching_vector);
if (preserve.marker != NULL)
bfd_preserve_restore (abfd, &preserve);
return FALSE;
1999-05-03 09:29:11 +02:00
}
/* Restore original target type and format. */
abfd->xvec = save_targ;
abfd->format = bfd_unknown;
bfd_set_error (bfd_error_file_ambiguously_recognized);
if (matching)
{
*matching = (char **) matching_vector;
matching_vector[match_count] = NULL;
/* Return target names. This is a little nasty. Maybe we
should do another bfd_malloc? */
while (--match_count >= 0)
{
const char *name = matching_vector[match_count]->name;
*(const char **) &matching_vector[match_count] = name;
}
}
else if (matching_vector)
free (matching_vector);
return FALSE;
1999-05-03 09:29:11 +02:00
}
/*
FUNCTION
bfd_set_format
SYNOPSIS
bfd_boolean bfd_set_format (bfd *abfd, bfd_format format);
1999-05-03 09:29:11 +02:00
DESCRIPTION
This function sets the file format of the BFD @var{abfd} to the
format @var{format}. If the target set in the BFD does not
support the format requested, the format is invalid, or the BFD
is not open for writing, then an error occurs.
*/
bfd_boolean
2003-06-29 12:06:40 +02:00
bfd_set_format (bfd *abfd, bfd_format format)
1999-05-03 09:29:11 +02:00
{
if (bfd_read_p (abfd)
|| (unsigned int) abfd->format >= (unsigned int) bfd_type_end)
2000-07-20 02:31:39 +02:00
{
bfd_set_error (bfd_error_invalid_operation);
return FALSE;
2000-07-20 02:31:39 +02:00
}
1999-05-03 09:29:11 +02:00
if (abfd->format != bfd_unknown)
return abfd->format == format;
1999-05-03 09:29:11 +02:00
2000-07-20 02:31:39 +02:00
/* Presume the answer is yes. */
1999-05-03 09:29:11 +02:00
abfd->format = format;
2000-07-20 02:31:39 +02:00
if (!BFD_SEND_FMT (abfd, _bfd_set_format, (abfd)))
{
abfd->format = bfd_unknown;
return FALSE;
2000-07-20 02:31:39 +02:00
}
1999-05-03 09:29:11 +02:00
return TRUE;
1999-05-03 09:29:11 +02:00
}
/*
FUNCTION
bfd_format_string
SYNOPSIS
const char *bfd_format_string (bfd_format format);
1999-05-03 09:29:11 +02:00
DESCRIPTION
Return a pointer to a const string
<<invalid>>, <<object>>, <<archive>>, <<core>>, or <<unknown>>,
depending upon the value of @var{format}.
*/
const char *
2003-06-29 12:06:40 +02:00
bfd_format_string (bfd_format format)
1999-05-03 09:29:11 +02:00
{
2003-06-29 12:06:40 +02:00
if (((int) format < (int) bfd_unknown)
|| ((int) format >= (int) bfd_type_end))
1999-05-03 09:29:11 +02:00
return "invalid";
2000-07-20 02:31:39 +02:00
switch (format)
{
case bfd_object:
return "object"; /* Linker/assembler/compiler output. */
case bfd_archive:
2000-07-20 02:31:39 +02:00
return "archive"; /* Object archive file. */
case bfd_core:
2000-07-20 02:31:39 +02:00
return "core"; /* Core dump. */
default:
2000-07-20 02:31:39 +02:00
return "unknown";
}
1999-05-03 09:29:11 +02:00
}