[PATCH] D79311: [lld-macho] Support X86_64_RELOC_SIGNED_{1,2,4}

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

In D79311#2018645 <https://reviews.llvm.org/D79311#2018645>, @int3 wrote:

> Thanks for putting this up!
>
> > See the comment in lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp RecordX86_64Relocation.
>
> The comment there confuses me a little:
>
>   // The Darwin x86_64 relocation format has a problem where it cannot
>   // encode an address (L<foo> + <constant>) which is outside the atom
>   // containing L<foo>. Generally, this shouldn't occur but it does
>   // happen when we have a RIPrel instruction with data following the
>   // relocation entry (e.g., movb $012, L0(%rip)). Even with the PCrel
>   // adjustment Darwin x86_64 uses, the offset is still negative and the
>   // linker has no way to recognize this.
>   
>
> It says "the linker has no way to recognize this", but it appears that the implicit addend already allows the linker to recognize it. Any idea why it also needs a special relocation type? Is it redundant / a mistake in the implementation? ("However, the specification or implementation of this seems to be incomplete..." seems to indicate that I guess.)


I guess X86_64_RELOC_SIGNED_1 can be used to assume the implicit addend is 1, i.e. it does not need to read the implicit addend at all (like ELF RELA). In binutils-gdb source code, the comment also implies the addends:

  /* Same as BFD_RELOC_32_PCREL but with an implicit -1 addend.  */
    BFD_RELOC_MACH_O_X86_64_PCREL32_1,
  
  /* Same as BFD_RELOC_32_PCREL but with an implicit -2 addend.  */
    BFD_RELOC_MACH_O_X86_64_PCREL32_2,
  
  /* Same as BFD_RELOC_32_PCREL but with an implicit -4 addend.  */
    BFD_RELOC_MACH_O_X86_64_PCREL32_4,

I played with X86MachObjectWriter.cpp a bit. We can simply treat `X86_64_RELOC_SIGNED_*` as `X86_64_RELOC_SIGNED`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D79311/new/

https://reviews.llvm.org/D79311