bug-binutils
[Top][All Lists]
Advanced

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

[Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary


From: cvs-commit at gcc dot gnu.org
Subject: [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary
Date: Wed, 17 Feb 2021 03:03:23 +0000

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

--- Comment #16 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot 
gnu.org> ---
The master branch has been updated by Nelson Chu <nelsonc1225@sourceware.org>:

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

commit 0d6aab77761274e479ca443f8bcb35a0eee3a4c4
Author: Nelson Chu <nelson.chu@sifive.com>
Date:   Thu Jan 21 18:16:12 2021 -0800

    RISC-V: PR27200, allow the first input non-ABI binary to be linked with any
one.

    RISC-V only defines two float ABIs, soft-float and double-float, and the
    value of soft-float is 0x0.  But 0x0 usually means unknown/default setting
    for many targets, and the non-ABI binary, which is generated by "ld/objcopy
    -b binary", also has the 0x0 elf header flags, this may be confused.

    We probably can define a new unknown/default ABI value to make them more
    clear, but that will need more bits in the elf header flags, and also need
    to discuss in the riscv psabi spec.

    Training linker have a default ABI setting, and can be changed by ld
    options or configure options is another solution, like what assemblr
    usually do.  So all objects, including the binary files, will have
    explicit ABI setting.  But the binary files will no longer be linked
    with any object, users need to recompile them with the exactly ABI
    they want.  It may be inconvenience sometimes.  Besides, I think linker
    doesn't need to know the default arch/abi so far, just set them according
    to the linked objects should be enough.

    Therefore, without changing the riscv psabi, and keep the non-ABI binary
    can be linked with any object, we don't check the ABI flags if no code
    section in the PR24389.  Just that we find the first input non-ABI binary
    still cannot be linked with others in the PR27200.  This patch fixs the
    problem by delaying the elf_flags_init(obfd) check, since the flags of
    non-ABI object with no code cannot be copyed to output BFD, we should
    skip it, even if it is the first linked object.

    However, there is a strange "break" at the end of loop in the PR24389.
    The "break" cause the ld testcase "Link with zlib-gabi compressed debug
    output 1" fails for rv64gc-linux toolchain, after applying the above
    change.  The root cause is that - the "break" make linker only checks
    the "first" section of input BFD rather than the entire sections.
    I have checked that AARCH64 and ARM both have the "break" at the end
    of loop, but ARC doesn't.  I suppose we should remove the "break" like
    what ARC do, or use a pair of braces for the if statement.

    I have passed the elf/linux toolchain regressions, so the change should
    be fine.

    bfd/
        PR 27200
        * elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Delay
        copying the elf flags from input BFD to output BFD, until we have
        checked if the input BFD has no code section or not.  Also fix the
        problem that we only check the first section rather than the entire
        sections for input BFD.

-- 
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]