[PATCH] D47507: [MC] [X86] Teach leaq _GLOBAL_OFFSET_TABLE(%rip), %r15 to use R_X86_64_GOTPC32 instead of R_X86_64_PC32

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

Apologies I don't know x86 well enough to be authoritative here. It looks like at least the test case needs to use %rip to see a meaningful difference in the output of mc.



================
Comment at: test/MC/ELF/relocation.s:43
         movl  $_GLOBAL_OFFSET_TABLE_, %eax
+        leaq  _GLOBAL_OFFSET_TABLE_(%rax), %r15
         movabs  $_GLOBAL_OFFSET_TABLE_, %rax
----------------
craig.topper wrote:
> If I just add this line to the test, I get the exact output shown in the check lines without any other changes.
Going back to the original example from the LLD review D47098 it seems that llvm-mc will emit a R_X86_64_PC32 relocation when the register is %rip but will use R_X86_64_GOTPC32 if the register is something like %rax. I'm guessing that this is because use of %rip means that the fixups are pc relative, when %rax is chosen the existing use of StartsWithGlobalOffsetTable for FK_DATA4, FK_DATA8 catches it.

For the somewhat arbitrary test:

```
        leaq _GLOBAL_OFFSET_TABLE_(%rip), %rax
        leaq _GLOBAL_OFFSET_TABLE_(%rax), %r15
```
mc gives me:
```
   0:	48 8d 05 00 00 00 00 	lea    0x0(%rip),%rax        # 0x7
			3: R_X86_64_PC32	_GLOBAL_OFFSET_TABLE_-0x4
   7:	4c 8d b8 00 00 00 00 	lea    0x0(%rax),%r15
			a: R_X86_64_GOTPC32	_GLOBAL_OFFSET_TABLE_+0x3
```
whereas gas gives me:

```
   0:	48 8d 05 00 00 00 00 	lea    0x0(%rip),%rax        # 0x7
			3: R_X86_64_GOTPC32	_GLOBAL_OFFSET_TABLE_-0x4
   7:	4c 8d b8 00 00 00 00 	lea    0x0(%rax),%r15
			a: R_X86_64_GOTPC32	_GLOBAL_OFFSET_TABLE_
```
Apologies I don't know enough about x86 to know which of mc or gas is correct in this case. The code in the ARM gas backend that chooses the got relative relocation did seem a bit loose to me so I'd get an x86 expert to check before assuming that gas is right.


Repository:
  rL LLVM

https://reviews.llvm.org/D47507