[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: |
bztemail at gmail dot com |
Subject: |
[Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary |
Date: |
Wed, 20 Jan 2021 16:23:53 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=27200
--- Comment #13 from bzt <bztemail at gmail dot com> ---
Hi Nelson,
I feel disturbance in the force... I'm using ftpmirror.gnu.org, which redirects
to a regional mirror. The 2.35 source I can download from there definitely
differs from yours, because according to your patch the function
_bfd_riscv_elf_merge_private_bfd_data starts at line 3804, but in the
downloaded source it's in line 3111 (so there must be quite a lot of
difference, ~700 SLoC at least!)
I've looked for another mirror (an unofficial github one), and compiling that
source produces an ld which can link font.o, *with* and *without* your patch. I
can also confirm that the order of the object files matter for riscv64,
riscv64-elf-ld font.o kernel.o -o kernel.elf
Doesn't work, but
riscv64-elf-ld kernel.o font.o -o kernel.elf
does! I guess it's the additional logic with "only_data_sections" flag that
solves the problem.
So while "ld -b binary" still doesn't set the ELF header ABI flag to the
default ABI, if I use that (unofficial) latest binutils source that doesn't
matter. I still think that ld should set exactly the same ELF settings as "as",
that would be the proper solution (I understand it supposed to be "not set",
but there's an issue with "not set" and "soft-float" on riscv).
How to proceed from now on, is up to you. For me this ticket changed from bug
to nice-to-have because my regional mirror should update sooner or later (I'm
terribly sorry that my regional mirror is so **** up), so my project will
compile with it without hacks. You can close it if you like, or you can try to
use the same ELF options in "ld" as in "as" and come up with a workaround for
"not set".
Cheers,
bzt
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, (continued)
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, address@hidden, 2021/01/18
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, bztemail at gmail dot com, 2021/01/18
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, bztemail at gmail dot com, 2021/01/18
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, bztemail at gmail dot com, 2021/01/18
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, address@hidden, 2021/01/18
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, bztemail at gmail dot com, 2021/01/18
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, nickc at redhat dot com, 2021/01/19
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, nickc at redhat dot com, 2021/01/19
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, nelson.chu1990 at gmail dot com, 2021/01/20
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, bztemail at gmail dot com, 2021/01/20
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary,
bztemail at gmail dot com <=
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, bztemail at gmail dot com, 2021/01/20
- [Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary, nelson.chu1990 at gmail dot com, 2021/01/21