https://sourceware.org/bugzilla/show_bug.cgi?id=18826
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |amodra at gmail dot com
Resolution|--- |INVALID
--- Comment #2 from Alan Modra <amodra at gmail dot com> ---
I'm closing the bug as invalid since it is clear to me that gas and ld are not
at fault here. Here's why:
The bug/limitation is really in the ABI. REL relocs are not the best choice
for targets like ARM and PowerPC that use multiple instructions to build an
address constant. You either store the same addend in each insn field (the
choice made by ARM), which limits the addend range, or you store parts of the
addend over multiple insns. The latter choice means the linker (and loader)
need to piece together the addend somehow, and in practical terms that limits
your code generation. The pieces need to be kept together, at least in the
same section and not have any other intervening insn requiring relocs. Which
is nasty, and IMO worse than the ARM choice.
Mixed rel/rela comes with its own set of problems. For instance, the rel and
rela relocs must be separated into two sections, because a relocation section
is a regular array of entries and the two types differ in size. If you wanted
both rel and rela output (dynamic) relocs, then you'd need a whole lot of
linker changes and you'd possibly need ld.so changes. (On the face of it,
ld.so looks like it supports both types, but I'm not aware of any target than
makes use of both rel and rela dynamic relocs, so that feature is untested.)
Besides that, having two dynamic reloc sections imposes an ordering on reloc
processing, which may clash with other requirements such as processing ifunc
relocs last.
Just switch to RELA.
--
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
