This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PR22458, failure to choose a matching ELF target
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Alan Modra <amodra at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Wed, 16 May 2018 06:45:57 -0700
- Subject: Re: PR22458, failure to choose a matching ELF target
- References: <20180516121542.GJ23663@bubble.grove.modra.org>
On Wed, May 16, 2018 at 5:15 AM, Alan Modra <amodra@gmail.com> wrote:
> 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.
>
> diff --git a/bfd/libbfd-in.h b/bfd/libbfd-in.h
> index 0c80f4d598..d8b445f894 100644
> --- a/bfd/libbfd-in.h
> +++ b/bfd/libbfd-in.h
> @@ -53,6 +53,9 @@ struct section_hash_entry
> asection section;
> };
>
> +/* Unique section id. */
> +extern unsigned int _bfd_section_id;
> +
Should it be marked as hidden?
--
H.J.