[Bug ld/27200] Bad RiscV64 ELF header flag using ld -b binary
https://sourceware.org/bugzilla/show_bug.cgi?id=27200
Nelson Chu changed:
What|Removed |Added
CC||nelson.chu1990 at gmail dot com
--- Comment #11 from Nelson Chu ---
Hi Guys,
Jim had resolved the similar problem before, here is the details,
https://sourceware.org/bugzilla/show_bug.cgi?id=24389
However, after the fixed, I think there is only one case that will cause the
"-b binary" cannot work expected - Link the binary file without any ABI setting
as the first linked object. The _bfd_riscv_elf_merge_private_bfd_data copy the
flags from input BFD to output BFD if elf_flags_init (obfd) is FALSE.
Therefore, we may copy the 0x0 flag from the binary file, if it is linked
first.
I suppose the Makefile in the Description should work, since the first linked
object is kernel.o rather than the binary font.o. However, the following
untested patch might work,
diff --git a/bfd/elfnn-riscv.c b/bfd/elfnn-riscv.c
index b2ec6a2..578b29a 100644
--- a/bfd/elfnn-riscv.c
+++ b/bfd/elfnn-riscv.c
@@ -3804,13 +3804,6 @@ _bfd_riscv_elf_merge_private_bfd_data (bfd *ibfd, struct
bfd_link_info *info)
new_flags = elf_elfheader (ibfd)->e_flags;
old_flags = elf_elfheader (obfd)->e_flags;
- if (! elf_flags_init (obfd))
-{
- elf_flags_init (obfd) = TRUE;
- elf_elfheader (obfd)->e_flags = new_flags;
- return TRUE;
-}
-
/* Check to see if the input BFD actually contains any sections. If not,
its flags may not have been initialized either, but it cannot actually
cause any incompatibility. Do not short-circuit dynamic objects; their
@@ -3836,7 +3829,18 @@ _bfd_riscv_elf_merge_private_bfd_data (bfd *ibfd, struct
bfd_link_info *info)
}
if (null_input_bfd || only_data_sections)
- return TRUE;
+ {
+ if (! elf_flags_init (obfd))
+ elf_elfheader (obfd)->e_flags = new_flags;
+ return TRUE;
+ }
+}
+
+ if (! elf_flags_init (obfd))
+{
+ elf_flags_init (obfd) = TRUE;
+ elf_elfheader (obfd)->e_flags = new_flags;
+ return TRUE;
}
At the beginning, I move "if (! elf_flags_init (obfd))" behind the input BFD
checking, to avoid copying the flags from the binary file with 0x0 flags. But
the change causes the ld testcase "Link with zlib-gabi compressed debug output
1" fails for rv64gc-linux toolchain... Therefore, I still copy the 0x0 flags
to the output BFD, if it is linked as the first files. But without turning the
elf_flags_init (obfd) to TRUE. This looks like a hack, but I don't know why
currently...
Thanks
Nelson
--
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
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #15 from Nelson Chu --- (In reply to bzt from comment #13) > 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. Yeah, Jim had solved this before, this behavior is what I expect. > 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. The fixed patch committed by Jim was in March/April 2019 before, so I suppose the recent official binutils should have the fix. > 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). I'm not sure if we need to do this, but we will discuss. It seems like we will only meet the problem that whether to generate the unknown/default abi flags when the input BFD are all "binaries". And if we set the default abi flags for those "binaries", then they can just be linked with the objects, which have the same abis. But shouldn't they be linked with any objects with any abi settings? Anyway, add a new "not set" abi flag should be the solution that same as most of targets, but we need to discuss this in the riscv psabi. > 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". That's fine, and thanks for raising this issue again. For now we do have the configure --with-arch option for assembler that can build it with the default architecture as user want, but not for linker. I'm not sure if linker needs to know the default arch/abi setting, I think linker just need to set them according to the linked objects. The "binary" file with the soft-float abi flag is really confused, but it would be great if there is any solution that don't need to change the psabi... The solution in the PR-24389 is the one, just need to find a way to resolve the problem if the "binary" file is linked as the first object. Anyway, I think this topic may be worth discussing on the psabi, to make sure if we really need to give the default soft/float abi flags for the "binary" file. If the conclusion is yes, then Nick's proposal patch is good :) Thanks Nelson -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27158] RISC-V port still has UJ instruction type references
https://sourceware.org/bugzilla/show_bug.cgi?id=27158 Nelson Chu changed: What|Removed |Added CC||nelson.chu1990 at gmail dot com --- Comment #1 from Nelson Chu --- Yeah and we also meet the same issue as SB type, it was changed to B-type in the new spec. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27348] obsolete Xcustom support in riscv port
https://sourceware.org/bugzilla/show_bug.cgi?id=27348 Nelson Chu changed: What|Removed |Added CC||nelson.chu1990 at gmail dot com --- Comment #3 from Nelson Chu --- Fixed. The remaining CUSTOM_[0|1|2] are used for .insn directive, so I keep them. Otherwise, all obsolete Xcustom stuff should be removed. Nelson -- 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
https://sourceware.org/bugzilla/show_bug.cgi?id=27200 --- Comment #17 from Nelson Chu --- I have passed the gcc/binutils regressions, the fixed patch should work. -- You are receiving this mail because: You are on the CC list for the bug.
