[llvm] MC: Centralize X86 PC-relative fixup adjustment in MCAssembler (PR #147113)

[Alexis Engelke via llvm-commits]

================
@@ -683,6 +683,35 @@ static unsigned getFixupKindSize(unsigned Kind) {
   }
 }
 
+// Adjust PC-relative fixup offsets, which are calculated from the start of the
+// next instruction.
+std::optional<bool> X86AsmBackend::evaluateFixup(const MCFragment &,
+                                                 MCFixup &Fixup,
+                                                 MCValue &Target, uint64_t &) {
+  if (Fixup.isPCRel()) {
+    switch (Fixup.getTargetKind()) {
+    case FK_Data_1:
+      Target.setConstant(Target.getConstant() - 1);
+      break;
+    case FK_Data_2:
+      Target.setConstant(Target.getConstant() - 2);
+      break;
+    default: {
+      Target.setConstant(Target.getConstant() - 4);
+      auto *Add = Target.getAddSym();
+      // If this is a pc-relative load off _GLOBAL_OFFSET_TABLE_:
+      // leaq _GLOBAL_OFFSET_TABLE_(%rip), %r15
+      // this needs to be a GOTPC32 relocation.
+      if (Add && Add->getName() == "_GLOBAL_OFFSET_TABLE_")
----------------
aengelke wrote:

I'm missing some context here. What fixup kinds, other than `X86::reloc_global_offset_table`, can end up hitting this code path? startsWithGlobalOffsetTable does some more checks, and is still called in emitImmediate -- could the different checks cause problems? I don't quite like duplicating checks for magical symbol names.. Couldn't we keep the GOT-check in emitImmediate and just adjust the offset here?

https://github.com/llvm/llvm-project/pull/147113