[ELF] Make R_I386_GOTPC and R_X86_64_GOTPC32/64 resolve to .got.plt.

[sivachandra]

Summary

These relocations are typically used to refer to the symbol
_GLOBAL_OFFSET_TABLE_. Since this symbol is at the beginning of
.got.plt, these relocations should resolve to .got.plt afterall.
This matches the behavior of ld.bfd and ld.gold.

[MaskRay]

I believe the patch in the current form will break some _GLOBAL_OFFSET_TABLE_ use cases (see https://reviews.llvm.org/D48095) so I volunteer to be a reviewer :)

_GLOBAL_OFFSET_TABLE_ : specifies the offset to the base of the GOT from the current code location.

The issue has been discussed a lot in https://bugs.llvm.org/show_bug.cgi?id=36555 . Some aspects in that thread no longer apply nowadays. I believe the remaining issue is that we have _GLOBAL_OFFSET_TABLE_ = end(.got) (lld's generalized R_*_FROM_END relocation types require this) but end(.got) != start(.got.plt) (we don't have a section rank rule for this).

As I noted in https://reviews.llvm.org/D56828 , after that patch we can make end(.got) = start(.got.plt) if we want and thus address the issue this patch intends to address. AFAIK no user application needs that but some ld.so implementations may want to have this property.

• More specifically, it allows to get rid of one lld-compatibility patch to glibc https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=575707c22f901b0adcce2478cc32da62afff287e
• Another instance I ran into was that llvm-mc emitted R_X86_64_GOTPC32 instead of R_X86_64_PC32 for leaq _GLOBAL_OFFSET_TABLE(%rip), %r15. I fixed that rule.

If people think that making end(.got) = start(.got.plt) is desirable I volunteer to do that, but it requires some more rules in Writer.cpp:getSectionRank?

[sivachandra]

In D59559#1435809, @MaskRay wrote:

I believe the patch in the current form will break some _GLOBAL_OFFSET_TABLE_ use cases (see https://reviews.llvm.org/D48095) so I volunteer to be a reviewer :)

Thanks, I did not know who the correct reviewer is, so I just added ruiu.

About "will break some _GLOBAL_OFFSET_TABLE_ use cases", can you elaborate which ones?

_GLOBAL_OFFSET_TABLE_ : specifies the offset to the base of the GOT from the current code location.

AFAIU, this convention you are quoting (from http://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf I believe) pertains to the assembly language usage. See Figure 3.12 for example.

However, _GLOBAL_OFFSET_TABLE_ is also an ELF symbol (which is unrelated to the offset convention above.) So, AFAIU, this patch does not break anything wrt the symbol _GLOBAL_OFFSET_TABLE_. But, you can point me to examples if that is the case.

The issue has been discussed a lot in https://bugs.llvm.org/show_bug.cgi?id=36555 . Some aspects in that thread no longer apply nowadays. I believe the remaining issue is that we have _GLOBAL_OFFSET_TABLE_ = end(.got) (lld's generalized R_*_FROM_END relocation types require this) but end(.got) != start(.got.plt) (we don't have a section rank rule for this).

Again AFAIU, where you place the symbol _GLOBAL_OFFSET_TABLE_ does not matter as long as it points to the zeroth location of the GOT (which is to say, the GOT itself.)

As I noted in https://reviews.llvm.org/D56828 , after that patch we can make end(.got) = start(.got.plt) if we want and thus address the issue this patch intends to address. AFAIK no user application needs that but some ld.so implementations may want to have this property.

I think, that we should/can have end(.got) = start(.got.plt) is a very desirable thing because, again according to the same ABI doc, one should allow negative indices into GOT. Since the zeroth location of GOT is start(.got.plt) by convention, negative indices into GOT are meaningful only if end(.got) = start(.got.plt).

Note that, this change also does not do anything wrt where the symbol _GLOBAL_OFFSET_TABLE_ is placed. What this change is essentially doing is to follow the ABI docs which say that R_I386_GOTPC, R_X86_64_GOTPC32/64 are all this:

GOT + A - P

In ld.lld, GOT is at start(.got.plt). So, this change is essentially making the above relocations resolve as start(.got.plt) + A - P. If ld.lld decides to place GOT at a different location, then we should update how these relocations resolve accordingly.

• More specifically, it allows to get rid of one lld-compatibility patch to glibc https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=575707c22f901b0adcce2478cc32da62afff287e

FWIW, an unrelated glibc use case is what drove me to this change.

If people think that making end(.got) = start(.got.plt) is desirable I volunteer to do that, but it requires some more rules in Writer.cpp:getSectionRank?

I do not have any practical examples at hand to prove/disprove if it is desirable or not. But, end(.got) = start(.got.plt) makes GOT contiguous and allows negative indices into GOT as required by the ABI doc. So, it is probably desirable.

[MaskRay]

About "will break some _GLOBAL_OFFSET_TABLE_ use cases", can you elaborate which ones?

See the example x86-64-reloc-gotoff64.s

With the patch, the sum doesn't compute addr(_DYNAMIC)

leaq _GLOBAL_OFFSET_TABLE_(%rip), %rdx ; R_X86_64_GOTPC32 (i.e R_GOTPLTONLY_PC): start(.got.plt)
movabsq $_DYNAMIC@GOTOFF, %rax         ; R_X86_64_GOTOFF64 (i.e R_GOTREL_FROM_END): addr(_DYNAMIC) - end(.got)
addq %rdx, %rax                        ; the sum is supposed to compute addr(_DYNAMIC)

So, AFAIU, this patch does not break anything wrt the symbol _GLOBAL_OFFSET_TABLE_. But, you can point me to examples if that is the case.

The current implementation in lld can have problems when there is a relocation type using _GLOBAL_OFFSET_TABLE_ as S, e.g. a R_X86_64_PC32 with S=_GLOBAL_OFFSET_TABLE_. This is different from R_X86_64_GOTPC32.

For the example above, suppose leaq _GLOBAL_OFFSET_TABLE_(%rip), %rdx emits R_X86_64_PC32 instead of R_X86_64_GOTPC32:

leaq _GLOBAL_OFFSET_TABLE_(%rip), %rdx ; R_X86_64_PC32: addr(_GLOBAL_OFFSET_TABLE_)
movabsq $_DYNAMIC@GOTOFF, %rax         ; R_X86_64_GOTOFF64 (i.e R_GOTREL_FROM_END): addr(_DYNAMIC) - end(.got)
addq %rdx, %rax                        ; addr(_GLOBAL_OFFSET_TABLE) = start(.got.plt) != end(.got), thus the sum is incorrect

I think, that we should/can have end(.got) = start(.got.plt) is a very desirable thing because, again according to the same ABI doc, one should allow negative indices into GOT. Since the zeroth location of GOT is start(.got.plt) by convention, negative indices into GOT are meaningful only if end(.got) = start(.got.plt).

Can you quote the exact sentences about negative indices into GOT in AMD64 psABI?

Regarding this part:

if (oneof<R_GOTONLY_PC, R_GOTPLTONLY_PC, R_GOTREL, R_GOTREL_FROM_END,
          R_PPC_TOC>(Expr))
  In.Got->HasGotOffRel = true;

After this patch, R_GOTPLTONLY_PC is unrelated to .got so it may look weird to suppress omission of .got when a R_GOTPLTONLY_PC is seen. However, we probably have to preserve that as _GLOBAL_OFFSET_TABLE_ is the base of GOT and it looks weird if .got disappears...

I've thought about the problem before and I think having end(.got) = start(.got.plt) is probably the best we can do to make everything compatible.

[sivachandra]

In D59559#1435826, @MaskRay wrote:

About "will break some _GLOBAL_OFFSET_TABLE_ use cases", can you elaborate which ones?

See the example x86-64-reloc-gotoff64.s

With the patch, the sum doesn't compute addr(_DYNAMIC)

leaq _GLOBAL_OFFSET_TABLE_(%rip), %rdx ; R_X86_64_GOTPC32 (i.e R_GOTPLTONLY_PC): start(.got.plt) + A - P
movabsq $_DYNAMIC@GOTOFF, %rax         ; R_X86_64_GOTOFF64 (i.e R_GOTREL_FROM_END): addr(_DYNAMIC) - end(.got)
addq %rdx, %rax                        ; the sum is supposed to compute addr(_DYNAMIC)

So, AFAIU, this patch does not break anything wrt the symbol _GLOBAL_OFFSET_TABLE_. But, you can point me to examples if that is the case.

The current implementation in lld can have problems when there is a relocation type using _GLOBAL_OFFSET_TABLE_ as S, e.g. a R_X86_64_PC32 with S=_GLOBAL_OFFSET_TABLE_. This is different from R_X86_64_GOTPC32.

For the example above, suppose leaq _GLOBAL_OFFSET_TABLE_(%rip), %rdx emits R_X86_64_PC32 instead of R_X86_64_GOTPC32:

leaq _GLOBAL_OFFSET_TABLE_(%rip), %rdx ; R_X86_64_PC32: addr(_GLOBAL_OFFSET_TABLE_) + A - P
movabsq $_DYNAMIC@GOTOFF, %rax         ; R_X86_64_GOTOFF64 (i.e R_GOTREL_FROM_END): addr(_DYNAMIC) - end(.got)
addq %rdx, %rax                        ; addr(_GLOBAL_OFFSET_TABLE) = start(.got.plt) != end(.got), thus the sum is incorrect

Yes, I have noticed the problem with R_X86_64_GOTOFF64 and I have another change for that which I have not completed because of other reasons [1]. But I did not bother in this change because this test, and the glibc example I have been using, do not fail after this change [2].

So, about R_X86_64_GOTOFF64, IMHO it is already broken in ld.lld. But, the test is passing and working as intended because the current implementations of GOTPC64 and GOTOFF64 are cancelling each other out [3]. The reason I say R_X86_64_GOTOFF64 is broken is because of this:

In ld.lld currently, R_X86_64_GOTOFF64 resolves as this:

Sym.getVA(A) - In.Got->getVA() - In.Got->getSize()

I think, it should actually be:

Sym.getVA(A) - In.GotPlt->getVA() // [4]

The reason why I think it should be expression [4] is because the ABI doc specifies R_X86_64_GOTOFF64 to resolve as:

S + A - GOT

In ld.lld, GOT is start(.got.plt). Hence, we should be resolving R_X86_64_GOTOFF64 as:

S + A - start(.got.plt)

Which is nothing but [4].

[1] - To fix R_X86_64_GOTOFF64 the right way, I really think we need .got and .got.plt to be adjacent as we need negative indices into GOT. May be this is _the_ reason why we should make end(.got) == start(.got.plt).
[2] - Glibc's X86_64 code uses extern long _DYNAMIC[] __attribute__((visibility("hidden"))); just like the test in question. However, it refers to only &_DYNAMIC, for which the compiler emits R_X86_64_PC32. Hence, we do not hit the problem with R_X86_64_GOTOFF64. What is broken for glibc without this change is a direct reference to _GLOBAL_OFFSET_TABLE_[0], for which the comiler produces GOTPC32.
[3] - R_X86_64_GOTPC64 is GOT + A - P; R_X86_64_GOTOFF64 is S + A - GOT. The assembly code in the test in question is effectively doing a sum of these two expressions:

GOT + A - P + S + A - GOT = 2A + S - P

The resulting expressing in the RHS is independent of GOT and hence the test works as expected currently.

PS: If we make end(.got) == start(.got.plt), then we should in principle not require this change. However, to avoid surprises while reading code, and to match what the ABI says in word, this change along with a change to R_X86_64_GOTOFF64 would still be nice.

[sivachandra]

BTW, I am not sure if makeing end(.got) = start(.got.plt) is a good idea because of this: https://fedoraproject.org/wiki/Changes/.got.plt_Isolation. It claims to have no ABI impact, but I am not sure how one can separate out .got.plt without ABI impact.

[MaskRay]

[2] - Glibc's X86_64 code uses extern long _DYNAMIC[] attribute((visibility("hidden"))); just like the test in question. However, it refers to only &_DYNAMIC, for which the compiler emits R_X86_64_PC32. Hence, we do not hit the problem with

glibc emits leaq _DYNAMIC(%rip), %rax (R_X86_64_PC32) because it assumes small code model. I agree that this patch won't break that. However, internally we have medium code model instruction sequences:

leaq _GLOBAL_OFFSET_TABLE_(%rip), %rdx
movabsq $_DYNAMIC@GOTOFF, %rax
addq %rdx, %rax

But, the test is passing and working as intended because the current implementations of GOTPC64 and GOTOFF64 are cancelling each other out [3]

Yes. Currently the example above relies on the cancellation effect.

In ld.lld currently, R_X86_64_GOTOFF64 resolves as this:

Sym.getVA(A) - In.Got->getVA() - In.Got->getSize()

Sym.getVA(A) - In.GotPlt->getVA() // [4]

Agree. Most In.Got->getVA() + In.Got->getSize() should be changed to In.GotPlt->getVA() to be compatible with the address of _GLOBAL_OFFSET_TABLE_.

If we replace all at once, we wouldn't need end(.got) == start(.got.plt).

Two relocation types can not have such simple transformation:

case R_TLSGD_GOT_FROM_END:
  return In.Got->getGlobalDynOffset(Sym) + A - In.Got->getSize();
case R_TLSLD_GOT_FROM_END:
  return In.Got->getTlsIndexOff() + A - In.Got->getSize();

[1] - To fix R_X86_64_GOTOFF64 the right way, I really think we need .got and .got.plt to be adjacent as we need negative indices into GOT. May be this is _the_ reason why we should make end(.got) == start(.got.plt).

Can you quote the paragraph where negative indices into GOT are used in i386/amd64 psABI?

PS: If we make end(.got) == start(.got.plt), then we should in principle not require this change. However, to avoid surprises while reading code, and to match what the ABI says in word, this change along with a change to R_X86_64_GOTOFF64 would still be nice.

Agree. See above, R_X86_64_PC32 and R_X86_64_GOTOFF64 should be fixed at the same time.

[MaskRay]

If there isn't a convincing reason .got and .got.plt should be adjacent, I think we probably don't need end(.got) == start(.got.plt) (I've changed my mind about that after investigating this more).

[sivachandra]

Can you quote the paragraph where negative indices into GOT are used in i386/amd64 psABI?

See the paragraph below Figure 5.1 on page 77 of http://refspecs.linuxbase.org/elf/x86_64-abi-0.99.pdf. Quoting here for convenience:

The symbol _GLOBAL_OFFSET_TABLE_ may reside in the middle of the
.got section, allowing both negative and non-negative offsets into the array of
addresses.

Thinking about it, I think I am mixing up things wrt R_X86_64_GOTOFF64. Implementing it as Sym.getVA(A) - In.GotPlt->getVA() over this change should just work IMHO. Let me try it tomorrow and get back to you.

[sivachandra]

In D59559#1435872, @MaskRay wrote:

If there isn't a convincing reason .got and .got.plt should be adjacent, I think we probably don't need end(.got) == start(.got.plt) (I've changed my mind about that after investigating this more).

Yes, I am likely mixing up things from other linkers vs how it is implemented in ld.lld. In ld.lld, for the reloc expression like G + GOT + A - P, we conveniently have Sym.getGotVA() as an equivalent of G + GOT eliminating a need for negative indices. So, I think end(.got) == start(.got.plt) is really not required.

[MaskRay]

In D59559#1435876, @sivachandra wrote:

In D59559#1435872, @MaskRay wrote:

If there isn't a convincing reason .got and .got.plt should be adjacent, I think we probably don't need end(.got) == start(.got.plt) (I've changed my mind about that after investigating this more).

Yes, I am likely mixing up things from other linkers vs how it is implemented in ld.lld. In ld.lld, for the reloc expression like G + GOT + A - P, we conveniently have Sym.getGotVA() as an equivalent of G + GOT eliminating a need for negative indices. So, I think end(.got) == start(.got.plt) is really not required.

I actually had a partial implementation on the stuff but haven't finished it yet (after I did the TLS stuff; I didn't know you are also working on glibc!).. Would you mind me finishing that and sending it for review :)

[sivachandra]

Not required anymore as https://reviews.llvm.org/D59594 has landed.

lld/ELF/Arch/X86.cpp

case R_386_TLS_LDM:
     return R_TLSLD_GOT_FROM_END;
   case R_386_PLT32:
     return R_PLT_PC;
   case R_386_PC8:
   case R_386_PC16:
   case R_386_PC32:
     return R_PC;
   case R_386_GOTPC:
-    return R_GOTONLY_PC_FROM_END;
+    return R_GOTPLTONLY_PC;
   case R_386_TLS_IE:
     return R_GOT;
   case R_386_GOT32:
   case R_386_GOT32X:
     // These relocations are arguably mis-designed because their calculations
     // depend on the instructions they are applied to. This is bad because we
     // usually don't care about whether the target section contains valid
     // machine instructions or not. But this is part of the documented ABI, so

lld/ELF/Arch/X86_64.cpp

RelExpr X86_64<ELFT>::getRelExpr(RelType Type, const Symbol &S,
   case R_X86_64_GOTPCRELX:
   case R_X86_64_REX_GOTPCRELX:
   case R_X86_64_GOTTPOFF:
     return R_GOT_PC;
   case R_X86_64_GOTOFF64:
     return R_GOTREL_FROM_END;
   case R_X86_64_GOTPC32:
   case R_X86_64_GOTPC64:
-    return R_GOTONLY_PC_FROM_END;
+    return R_GOTPLTONLY_PC;
   case R_X86_64_NONE:
     return R_NONE;
   default:
     error(getErrorLocation(Loc) + "unknown relocation (" + Twine(Type) +
           ") against symbol " + toString(S));
     return R_NONE;
   }
 }

lld/ELF/InputSection.cpp

case R_ADDEND:
     return A;
   case R_ARM_SBREL:
     return Sym.getVA(A) - getARMStaticBase(Sym);
   case R_GOT:
   case R_RELAX_TLS_GD_TO_IE_ABS:
     return Sym.getGotVA() + A;
   case R_GOTONLY_PC:
     return In.Got->getVA() + A - P;
-  case R_GOTONLY_PC_FROM_END:
-    return In.Got->getVA() + A - P + In.Got->getSize();
+  case R_GOTPLTONLY_PC:
+    return In.GotPlt->getVA() + A - P;
   case R_GOTREL:
     return Sym.getVA(A) - In.Got->getVA();
   case R_GOTREL_FROM_END:
     return Sym.getVA(A) - In.Got->getVA() - In.Got->getSize();
   case R_GOT_FROM_END:
   case R_RELAX_TLS_GD_TO_IE_END:
     return Sym.getGotOffset() + A - In.Got->getSize();
   case R_TLSLD_GOT_OFF:

lld/ELF/Relocations.h

 // List of target-independent relocation types. Relocations read
 // from files are converted to these types so that the main code
 // doesn't have to know about architecture-specific details.
 enum RelExpr {
   R_ABS,
   R_ADDEND,
   R_GOT,
   R_GOTONLY_PC,
-  R_GOTONLY_PC_FROM_END,
+  R_GOTPLTONLY_PC,
   R_GOTREL,
   R_GOTREL_FROM_END,
   R_GOT_FROM_END,
   R_GOT_OFF,
   R_GOT_PC,
   R_HINT,
   R_NEG_TLS,
   R_NONE,

lld/ELF/Relocations.cpp

 // dynamic relocation so that the relocation will be fixed at load-time.
 static bool isStaticLinkTimeConstant(RelExpr E, RelType Type, const Symbol &Sym,
                                      InputSectionBase &S, uint64_t RelOff) {
   // These expressions always compute a constant
   if (oneof<R_GOT_FROM_END, R_GOT_OFF, R_HEXAGON_GOT, R_TLSLD_GOT_OFF,
             R_MIPS_GOT_LOCAL_PAGE, R_MIPS_GOTREL, R_MIPS_GOT_OFF,
             R_MIPS_GOT_OFF32, R_MIPS_GOT_GP_PC, R_MIPS_TLSGD,
             R_AARCH64_GOT_PAGE_PC, R_GOT_PC, R_GOTONLY_PC,
-            R_GOTONLY_PC_FROM_END, R_PLT_PC, R_TLSGD_GOT, R_TLSGD_GOT_FROM_END,
+            R_GOTPLTONLY_PC, R_PLT_PC, R_TLSGD_GOT, R_TLSGD_GOT_FROM_END,
             R_TLSGD_PC, R_PPC_CALL_PLT, R_TLSDESC_CALL, R_AARCH64_TLSDESC_PAGE,
             R_HINT, R_TLSLD_HINT, R_TLSIE_HINT>(E))
     return true;
 
   // These never do, except if the entire file is position dependent or if
   // only the low bits are used.
   if (E == R_GOT || E == R_PLT || E == R_TLSDESC)
     return Target->usesOnlyLowPageBits(Type) || !Config->Pic;
if (!Sym.IsPreemptible && !Sym.isGnuIFunc()) {
     if (Expr == R_GOT_PC && !isAbsoluteValue(Sym))
       Expr = Target->adjustRelaxExpr(Type, RelocatedAddr, Expr);
     else
       Expr = fromPlt(Expr);
   }
 
   // This relocation does not require got entry, but it is relative to got and
   // needs it to be created. Here we request for that.
-  if (oneof<R_GOTONLY_PC, R_GOTONLY_PC_FROM_END, R_GOTREL, R_GOTREL_FROM_END,
+  if (oneof<R_GOTONLY_PC, R_GOTPLTONLY_PC, R_GOTREL, R_GOTREL_FROM_END,
             R_PPC_TOC>(Expr))
     In.Got->HasGotOffRel = true;
 
   // Read an addend.
   int64_t Addend = computeAddend<ELFT>(Rel, End, Sec, Expr, Sym.isLocal());
 
   // Process some TLS relocations, including relaxing TLS relocations.
   // Note that this function does not handle all TLS relocations.

lld/test/ELF/i386-gotpc-dynamic.s

 # CHECK-NEXT:   Address: 0x2030
 # CHECK-NEXT:   Offset:
 # CHECK-NEXT:   Size:
 # CHECK-NEXT:   Link:
 # CHECK-NEXT:   Info:
 # CHECK-NEXT:   AddressAlignment:
 # CHECK-NEXT:   EntrySize:
 # CHECK-NEXT: }
+# CHECK-NEXT:  Section {
+# CHECK-NEXT:   Index: 8
+# CHECK-NEXT:   Name: .got.plt
+# CHECK-NEXT:   Type: SHT_PROGBITS
+# CHECK-NEXT:   Flags [
+# CHECK-NEXT:     SHF_ALLOC
+# CHECK-NEXT:     SHF_WRITE
+# CHECK-NEXT:   ]
+# CHECK-NEXT:   Address: 0x3000
+# CHECK-NEXT:   Offset:
+# CHECK-NEXT:   Size:
+# CHECK-NEXT:   Link:
+# CHECK-NEXT:   Info:
+# CHECK-NEXT:   AddressAlignment:
+# CHECK-NEXT:   EntrySize:
+# CHECK-NEXT: }
 
-## 0x1000 + 4144 = 0x2030
-# DISASM: 1000: {{.*}} movl $4144, %eax
+## 0x3000 - 0x1000 = 8192
+# DISASM: 1000: {{.*}} movl $8192, %eax
 
 .section .foo,"ax",@progbits
 foo:
- movl $bar@got-., %eax # R_386_GOTPC
+ movl $_GLOBAL_OFFSET_TABLE_@got-., %eax # R_386_GOTPC
 
 .local bar
 bar:

lld/test/ELF/i386-gotpc.s

 // CHECK-NEXT: Flags [
 // CHECK-NEXT:   SHF_ALLOC
 // CHECK-NEXT:   SHF_WRITE
 // CHECK-NEXT: ]
 // CHECK-NEXT: Address: 0x3000
 
 // DISASM:      Disassembly of section .text:
 // DISASM-NEXT: .text:
-// DISASM-NEXT:    1000: {{.*}}         movl    $4144, %eax
-//                                              0x2030 - 0x1000 = 0x1030
+// DISASM-NEXT:    1000: {{.*}}         movl    $8192, %eax
+//                                              0x3000 - 0x1000 = 8192

lld/test/ELF/relocation-i686.s

 .section .R_386_GOTPC,"ax",@progbits
 R_386_GOTPC:
  movl $_GLOBAL_OFFSET_TABLE_, %eax
 
 // 0x402078 + 8 - 0x401014 = 8300
 
 // CHECK:      Disassembly of section .R_386_GOTPC:
 // CHECK-NEXT: R_386_GOTPC:
-// CHECK-NEXT:   401014:  {{.*}} movl  $4204, %eax
+// CHECK-NEXT:   401014:  {{.*}} movl  $8172, %eax
 
 .section .dynamic_reloc, "ax",@progbits
  call bar
 // addr(.plt) + 16 - (0x401019 + 5) = 50
 // CHECK:      Disassembly of section .dynamic_reloc:
 // CHECK-NEXT: .dynamic_reloc:
 // CHECK-NEXT:   401019:  e8 32 00 00 00 calll 50
 

lld/test/ELF/x86-64-reloc-gotoff64.s

 // REQUIRES: x86
 // RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
 // RUN: ld.lld %t.o -shared -o %t.so
 // RUN: llvm-readelf -S %t.so | FileCheck %s -check-prefix=SECTION
 // RUN: llvm-objdump -d %t.so | FileCheck %s
 
 // SECTION: .dynamic DYNAMIC 0000000000002000
 // SECTION: .got PROGBITS 0000000000002070 002070 000000
+// SECTION: .got.plt PROGBITS 0000000000003000 003000 000018
 
 // All the _GLOBAL_OFFSET_TABLE_ occurrences below refer to the address
 // of GOT base, not the address of the symbol _GLOBAL_OFFSET_TABLE_. These
 // instructions are special and produce GOT base relative relocations. We
 // currently use .got end as the GOT base, which is not equal to
 // the address of the special symbol _GLOBAL_OFFSET_TABLE_.
 
 // The assembly is generated by
 // gcc -O2 -S -mcmodel=medium -fPIC a.c
 // This computes the pc-relative address (runtime address) of _DYNAMIC.
 //
 // extern long _DYNAMIC[] __attribute__((visibility("hidden")));
 // long* dynamic() { return _DYNAMIC; }
 
-// 0x2070 (.got end) - 0x1007 = 4201
+// 0x3000 (.got.plt start) - 0x1007 = 8185
 // 0x2000 (_DYNAMIC) - 0x2070 (.got end) = -112
-// CHECK:      1000: {{.*}} leaq 4201(%rip), %rdx
+// CHECK:      1000: {{.*}} leaq 8185(%rip), %rdx
 // CHECK-NEXT: 1007: {{.*}} movabsq $-112, %rax
 .global dynamic
 dynamic:
   leaq _GLOBAL_OFFSET_TABLE_(%rip), %rdx
   movabsq $_DYNAMIC@GOTOFF, %rax
   addq %rdx, %rax
   ret

lld/test/ELF/x86-64-reloc-gotpc64.s

 // REQUIRES: x86
 // RUN: llvm-mc -filetype=obj -triple=x86_64-pc-linux %s -o %t.o
 // RUN: ld.lld %t.o -shared -o %t.so
 // RUN: llvm-readelf -S %t.so | FileCheck %s -check-prefix=SECTION
 // RUN: llvm-objdump -d %t.so | FileCheck %s
 
 // SECTION: .got PROGBITS 0000000000002070 002070 000000
+// SECTION: .got.plt PROGBITS 0000000000003000 003000 000018
 
-// 0x2070 (.got end) - 0x1000 = 4208
+// 0x3000 (.got.plt start) - 0x1000 = 8192
 // CHECK: gotpc64:
-// CHECK-NEXT: 1000: {{.*}} movabsq $4208, %r11
+// CHECK-NEXT: 1000: {{.*}} movabsq $8192, %r11
 .global gotpc64
 gotpc64:
   movabsq $_GLOBAL_OFFSET_TABLE_-., %r11