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

[nelson.chu1990 at gmail dot com]

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

--- Comment #15 from Nelson Chu <nelson.chu1990 at gmail dot com> ---
(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.