https://sourceware.org/bugzilla/show_bug.cgi?id=23244
Jim Wilson <wilson at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-05-30
CC| |wilson at gcc dot gnu.org
Assignee|unassigned at sourceware dot org |wilson at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
I see the problem. This is working for 32-bit targets, and failing for 64-bit
targets. For a 32-bit target, the offset ends up as 0x70000000 which when
added to 0x90000000 via auipc gives zero. But for a 64-bit target, the
addition gives 0x100000000 which is not the right address. We can only address
+/- 0x80000000 from the current PC, which means address zero is not in range.
The other part of this problem is that relaxation is deliberately disabled for
weak functions, as the address might change later when another object file or
library is added in.
I think the only easy workaround at the moment would be to use riscv32 instead
of riscv64.
I think we would need a new code model to make this work for riscv64.
Or alternatively compile with -fpie, which then indirects via the GOT which
will be in range, but requires dynamic linker support.
There might be a more complex way to fix this by changing how the R_RISCV_CALL
relocation works, so that it writes both instruction opcodes and fields, in
which case we can handle a zero address directly, or alternatively we can relax
it multiple times. I'm not sure if this can work, and may not have time to try
it for a while.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
