[PATCH] D91993: [ELF] Don't relax R_X86_64_GOTPCRELX if addend != -4

Fangrui Song via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 24 10:11:45 PST 2020

MaskRay added a comment.

In D91993#2414225 <https://reviews.llvm.org/D91993#2414225>, @MaskRay wrote:

> In D91993#2413016 <https://reviews.llvm.org/D91993#2413016>, @grimar wrote:
>> My understanding is that R_X86_64_*RELX relocation should never be emitted when a relaxation is not possible.
>> ABI doesn't say anything about addends I think ("B.2 Optimize GOTPCRELX Relocations", p151, https://raw.githubusercontent.com/wiki/hjl-tools/x86-psABI/x86-64-psABI-1.0.pdf).
>> So, why should this be handled on linker side and not on the compiler side?
> There are two questions:
> - Whether `movl x at GOTPCREL+4(%rip), %eax` is valid?
> - Whether the expression should assemble to `R_X86_64_GOTPCRELX`?
> For the first, I tend to think it is valid - this allows the compiler generates an instruction to load the half part of the GOT entry.
> For the second, my understanding is that `R_X86_64_GOTPCREL` can be entirely replaced by `R_X86_64_[REX_]GOTPCRELX`. If so, it is certainly reasonable to assemble to `R_X86_64_GOTPCRELX`. I can send a clarification on binutils, though.

Asked on binutils and HJ Lu said  `movl x at GOTPCREL+4(%rip), %eax` is valid (https://sourceware.org/pipermail/binutils/2020-November/114264.html)
So I think we should proceed with this patch. I also created a gold bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=26939

  rG LLVM Github Monorepo



More information about the llvm-commits mailing list