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

[nickc at redhat dot com]

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

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-01-19
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1
                 CC|                            |nickc at redhat dot com

--- Comment #9 from Nick Clifton <nickc at redhat dot com> ---
Hi 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". 
This means that there is no way for the linker (or assembler) to create an
object file with no flags set.  The situation is unfortunate, but obviously
cannot be changed now.

  Problems arise however when trying to link these binary object files with
real risc-v object files.  Imagine for example an extended version of your test
case from comment #6:

  % as a.s -o c.o -mabi=lp64
  % readelf -h c.o | grep Flags
  Flags:                             0x0

  % ld c.o font.o

What should happen here ?  If font.o is treated as having the default ABI flags
then it will not be possible to link it with c.o.  But font.o is a "binary"
file with no real ABI needs at all.  IE it ought to be possible to link it to
both soft-float and double-float objects.  (And quad-float too).

So in theory what the linker should do is scan all of the input files.  If any
of them are riscv files then their flags should be compared and used to set the
flags of the output file.  If none of them are riscv files (ie they are binary
blobs) then the default ABI flags should be set instead.  Do you agree ?

Assuming that you do, please could you try out the patch that I am about to
upload and let me know if it solves the problem for you.

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.