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

2021-01-20 Thread bztemail at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #14 from bzt --- FYI, I've used this mirror: https://github.com/bminor/binutils-gdb/blob/master/bfd/elfnn-riscv.c Here _bfd_riscv_elf_merge_private_bfd_data starts at line 3781, so it's not exactly the same as yours either, but th

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

2021-01-20 Thread bztemail at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #13 from bzt --- 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 p

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

2021-01-20 Thread bztemail at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #12 from bzt --- > OK, so part of the problem is for the RISC-V, if the the ELF header flags are > zero then this means "uses soft float", rather than "no flags have been set". Yes, agreed. The other part being not been able to s

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

2021-01-18 Thread bztemail at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #8 from bzt --- > The input has no branding, so the linker cannot invent it. But it does invent it, that's the problem! "ld" should just use the default ABI for the platform, the same as all the other tool use. Not inventing up "s

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

2021-01-18 Thread bztemail at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #6 from bzt --- Look: $ cat a.s .globl _start .text _start: ret $ riscv64-elf-as -c a.s -o a.o $ riscv64-elf-readelf -h a.o | grep Flags Flags: 0x4 double-float ABI $ riscv64-elf-ld a.o -o a $ riscv64

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

2021-01-18 Thread bztemail at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #4 from bzt --- > That's the point. Using ld -b binary is not a good way to wrap binary blobs. Bad point! Forcing additional assembly on all language and architecture combinations? An unacceptable additional complexity to the bui

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

2021-01-18 Thread bztemail at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #5 from bzt --- Or let me rephrase: ld generating an Elf header with an emulation that it wasn't configured for is a bug. 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

2021-01-18 Thread bztemail at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #2 from bzt --- No assembler used in this project. FYI, this works with x86_64 and aarch64 only risv64 affected. I also have C++, Pascal, Rust versions of kernel.c, those must be linked with font.o too, so this needs to be a langu

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

2021-01-18 Thread bztemail at gmail dot com
Component: ld Assignee: unassigned at sourceware dot org Reporter: bztemail at gmail dot com Target Milestone: --- Dear binutils developers, I've found an issue with the latest GNU ld in binutils about generating RiscV64 ELF headers. ENVIRONMENT I'm compili