This is an archive of the discontinued LLVM Phabricator instance.

[MC][PowerPC] Emit R_PPC_UADDR32 and R_PPC64_UADDR64 if r_offset is misaligned
AbandonedPublic

Authored by MaskRay on Aug 12 2019, 12:49 AM.

Details

Summary

R_PPC_ADDR32 and R_PPC64_ADDR64 may be emitted at misaligned r_offset.
This does not conform to the ABIs.

32-bit psABI says:

word32
Specifies a 32-bit bit-field taking up 4 bytes maintaining 4-byte alignment unless otherwise indicated.

ELFv2 ABI says:

doubleword64 specifies a 64-bit field occupying 8 bytes, the alignment of which is 8 bytes unless otherwise specified.

R_PPC_UADDR32 and R_PPC64_UADDR64 belong to the word32 and doubleword64 classes, respectively.

This patch fixes the problem by teaching ELFWriter::writeRelocations to
emit UADDR if an ADDR has a misaligned r_offset. This cannot be done in
the derived MCELFObjectTargetWriter::getRelocType because r_offset is
not known there.

When objects are linked into executable/DSO:

  • If sh_addralign >= 8, an R_PPC64_ADDR64 whose r_offset%8!=0 is guaranteed to have a misaligned address.
  • Otherwise, it may have an aligned address if the relocated section is combined with other sections, e.g.
.section .data,"aw",@progbits,unique,0; .align 8; .byte 0
.section .data,"aw",@progbits,unique,1; .space 7; .long a

UADDR are rare: they are caused by initialized data at misaligned
addresses (e.g. attribute((packed))). So we don't necessarily
optimize for them.

This change also simplifies the linker design. Since R_PPC64_ADDR64 will
be guaranteed to be aligned, we can safely emit dynamic R_PPC64_RELATIVE
for R_PPC64_ADDR64 to a non-preemptable symbol in a writable location.
(Currently lld ppc{32,64} and ld.bfd ppc32 can emit misaligned
R_PPC{,64}_RELATIVE. This is not a big problem - kernels (verified with Linux
and FreeBSD) trap handlers will fix misaligned accesses).)

Diff Detail

Event Timeline

MaskRay created this revision.Aug 12 2019, 12:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 12 2019, 12:49 AM
MaskRay abandoned this revision.Aug 12 2019, 2:56 AM

Probably not worth the trouble: rL177160 , newer ppc64 processors can do unaligned memory access nearly as efficient as aligned accesses? If that is true, we should not do misaligned ADDR -> UADDR transforms as powerpc64 ld.bfd does (https://sourceware.org/bugzilla/show_bug.cgi?id=24896)