bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/22458] libbfd fails to detect elf32-littlearm target when


From: cvs-commit at gcc dot gnu.org
Subject: [Bug binutils/22458] libbfd fails to detect elf32-littlearm target when it is compiled with support for all targets
Date: Wed, 16 May 2018 12:16:51 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=22458

--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot 
gnu.org> ---
The master branch has been updated by Alan Modra <address@hidden>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7cf7fcc83ca9fb4c4b591b3142bcf12e6e8a2aa5

commit 7cf7fcc83ca9fb4c4b591b3142bcf12e6e8a2aa5
Author: Alan Modra <address@hidden>
Date:   Wed May 16 11:33:48 2018 +0930

    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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]