[PATCH] D47098: [ELF] Make R_GOTONLY_PC_FROM_END R_GOTREL_FROM_END relative to _GLOBAL_OFFSET_TABLE_ instead of end of .got

[Fangrui Song via Phabricator via llvm-commits]

MaskRay marked 4 inline comments as done.
MaskRay added inline comments.


================
Comment at: test/ELF/x86-64-reloc-shared.s:17
+R_X86_64_GOTPC64:
+  movabsq $_GLOBAL_OFFSET_TABLE_-., %r11
----------------
grimar wrote:
> peter.smith wrote:
> > grimar wrote:
> > > MaskRay wrote:
> > > > grimar wrote:
> > > > > What I see is that llvm-mc produce following relocations here for me:
> > > > > 
> > > > > ```
> > > > > 000000000003  000300000002 R_X86_64_PC32     0000000000000000 _GLOBAL_OFFSET_TABLE_ - 4
> > > > > 000000000009  00030000001d R_X86_64_GOTPC64  0000000000000000 _GLOBAL_OFFSET_TABLE_ + 2
> > > > > ```
> > > > > 
> > > > > So R_X86_64_GOTPC32 seems to be uncovered be this test.
> > > > `R_X86_64_GOTPC32` is a special case of `R_X86_64_PC32` where the symbol is `_GLOBAL_OFFSET_TABLE_`. GNU as emits `R_X86_64_GOTPC32` but llvm-mc emits `R_X86_64_PC32`. I have also tested GNU as 
> > > If llvm-mc is unable to generate inputs for the test, you can use yaml2obj to craft objects.
> > > (For example, see `ELF\invalid\invalid-relocation-x64.test`)
> > > 
> > > But currently the R_X86_64_GOTPC32 is untested by your test case and that is not OK.
> > Arm has a similar discrepancy between GNU as and llvm-mc. GNU as will use R_ARM_BASE_PREL if there is a relative relocation to _GLOBAL_OFFSET_TABLE_, this is useful as the relocation doesn't depend on the value of _GLOBAL_OFFSET_TABLE_. I submitted https://reviews.llvm.org/D46319 to see if I could get this fixed for Arm but I didn't get any response for it.
> Yeah, I did not mean we need to fix llvm-mc, but at least I think we should test the particular relocation with use of yaml2obj then.
Thanks for the suggestion. I learned yaml2obj and added test/ELF/x86-64-reloc-shared2.test


Repository:
  rLLD LLVM Linker

https://reviews.llvm.org/D47098