https://sourceware.org/bugzilla/show_bug.cgi?id=24896
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |amodra at gmail dot com
Resolution|--- |WONTFIX
--- Comment #2 from Alan Modra <amodra at gmail dot com> ---
ld selects R_PPC64_UADDR*/R_PPC64_ADDR* depending on their alignment for
dynamic relocations, and glibc ld.so applies them taking into account that
R_PPC64_UADDR* may not be aligned whereas all other dynamic relocs (including
R_PPC64_RELATIVE) are assumed to be aligned. This mattered when we were
developing the ppc64le support on power7 processors. (Yes, ppc64le was
originally supported on power7 even though the hardware support for
little-endian was somewhat lacking, leading to lots of alignment traps on
mis-aligned memory accesses.)
It's true that a strict interpretation of the relevant ABI documents would
require assemblers to generate UADDR relocs in a lot more cases, but we haven't
done that and I don't see any good reason to modify gas to do that now. At
worst it might cause some linkers running on old hardware to take alignment
traps when processing object files, slowing down the linker a little. Slightly
slower tools don't matter.
On power8 and later, with glibc ld.so compiled for power8, you should see the
R_PPC64_UADDR* relocs being processed just like the corresponding R_PPC64_ADDR*
reloc (ie. using full width memory writes rather than multiple byte writes).
So there isn't much reason to avoid R_PPC64_UADDR* relocs.
--
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
