[LLD][ARM] ARM IRELATIVE relocations are in rel.dyn

[peter.smith]

Summary

The existing code for IRELATIVE relocations in ARM uses the built-in support by setting Target->IRelativeRel to R_ARM_IRELATIVE.
Unfortunately when trying to run a lld produced executable with an IRELATIVE relocation using the glibc dynamic loader ld-linux-armhf.so.3 I get an "unexpected PLT reloc type" error message.

Looking into sysdeps/arm/dl-machine.h it seems like R_ARM_IRELATIVE is only supported in the rel.dyn section of the PLT. This is probably a legacy of ARM having a single .got section.

This change does the following for ARM targets:

• Puts the got entry used by the IRELATIVE relocation into .got rather than .got.plt
• Puts the IRELATIVE relocation into .rel.dyn rather than .rel.plt
• defines rel_iplt_start and rel_iplt_end around .rel.dyn rather than .rel.plt
• Always adds .rel.dyn when there are IRELATIVE relocations even when static linking. This follows the same pattern as .rel.plt
• Passes the GotVA of the symbol to the PLT generation code rather than the GotPltVA for an ARM IRelative relocation
• If there is no .got.plt section (static linking) then use a dummy zero address for the PLT header as there is no .got.plt address.

Review questions:

• This patch is a bit messy, but I've not got many ideas that would make it much cleaner. It is possible that some of the tests could be moved into functions and they could be abstracted away from ARM, for example if (Target->IRelInPLT) ...
• On ARM GNU ld can use an auxiliary PLT OutputSection called .iplt exclusively for ifuncs. Following this implementation choice might make the implementation a little cleaner in some places but it would probably mean more code-changes overall.
• It could be possible to not output the PLT header if there are only IRELATIVE entries, this would mean changing some code that has assumptions that there is always a PLT header.

Unfortunately the static glibc has an IRELATIVE relocation for memcpy on ARM so anyone trying to do static linking will hit the error message.

dl-machine.h reference:
https://fossies.org/dox/glibc-2.24/arm_2dl-machine_8h_source.html
The .rel.plt code is elf_machine_lazy_rel() at the bottom of the file. The .rel.dyn is elf_machine_rela()

x86_64, x86_32 and AArch64 has IRELATIVE support in both functions, ppc64 like ARM only has support in rel.dyn. The lld support for ppc doesn't support IRELATIVE so there isn't anything broken there.

[ruiu]

Hmm, it is not indeed your fault, but it is a bit messy because the problem it is handling is an arbitrary ABI limitation. (Is there any effort going on to fix it on the loader side?)

I'm wondering if it can be solved by merging .got.plt into .got. Once the conversion of linker-synthesized section is done, you'll get .got.plt as an input section, so you can put it into any output section, even into .got. Does it solve the issue?

[peter.smith]

As far as I know there isn't any existing effort to fix the loader as the loader will happily will work with gold and bfd as they are Today. Even if the loader is modified there will be a delay until Linux distributions pick it up as the glibc release cycle can be quite long (ld.so is part of glibc) and many existing installations that will remain on the old library. I think it is worth at least reporting to glibc, but practically speaking I think we'll have to follow the existing conventions.

I think merging the .got and .got.plt solves one of the cases, whether to put the .got entry into .got.plt or .got, but it doesn't solve the problem that the relocation will need to go into .rel.dyn and not .rel.plt, and that is the majority of the mess. Unfortunately we can't merge .rel.plt and .rel.dyn so most of the special cases will still exist.

I can have a go at adding some helper function to see if I can clear up the main code path.

Turning the problem on its head I did consider whether it would be worth making all the other Targets use rel.dyn rather than .rel.plt, this would unify the implementations using the ARM way. However it seems like other linker's like ld don't do this on Targets like x86 and try to avoid doing so where possible so I'm reluctant to do this given how poorly specified all this is.

As an aside while looking into ifunc support in other linkers I came across: https://sourceware.org/bugzilla/show_bug.cgi?id=13302 which makes sure IRELATIVE relocations are always sorted to appear after non IRELATIVE relocations, this avoids corner cases where the IFUNC resolver refers to a PLT entry that hasn't been relocated yet. I don't think that lld does this at the moment so we would presumably be vulnerable to the same corner case.

[peter.smith]

On reflection I think that it could be possible to clean this up if the rel.dyn and rel.plt OutputSections are rewritten in terms of InputSections. The linker in Relocation.cpp would create the R_<TARGET>_IRELATIVE relocations in an InputSection called .rel.iplt or .rela.iplt. On targets such as AArch64 and X86 rela.iplt would be allocated to the .rela.plt OutputSection, on ARM and PPC (if the PPC lld Target supported it) would go into the .rel.dyn OutputSection.

The PLT and GOT + Relocs as InputSection may be some way off, is there any chance of tidying the code up enough or does it need to wait for the InputSection work to complete? The static glibc uses IFunc for memcpy which is used during initialisation so it will block all static linking on ARM.

[ruiu]

In an attempt to understand the problem more, I tried to read GNU libc's code, but couldn't even figure out where it distinguishes .rel.dyn from .rel.plt. Could you point it for me?

[peter.smith]

To the best of my knowledge from grepping through the code, I'm no glibc expert unfortunately, I think a good place to start from is do-rel.h in the elf sub-directory of glibc:
https://fossies.org/dox/glibc-2.24/do-rel_8h_source.html
This has elf_dynamic_do_Rel which is the code that iterates over the Relocations in .rel.plt or .rel.dyn.

Another useful file is dynamic-link.h also in the elf sub-directory https://fossies.org/dox/glibc-2.24/dynamic-link_8h_source.html
This contains the _ELF_DYNAMIC_DO_RELOC which gets the range information for .rel.plt and .rel.dyn from the .dynamic segment/section tags such as DT_REL and DT_JMPREL. The appropriate REL or RELA version of elf_dynamic_do_Rel is called from here with the relocation information from either .rel.plt or .rel.dyn (Line 160).

The definition of elf_machine_lazy_rel (PLT) or elf_machine_rel (GOT) are in sysdeps/<TARGET>/dl-machine.h

At this stage elf_machine_lazy_rel won't do the relocation for relocations such as R_*_JUMP_SLOT, but will instead set up the .got.plt to point to the resolver. Interestingly for R_*_IRELATIVE the ifunc resolver is called so there is no lazy evaluation of the resolution.

Hope this is of some use.

[peter.smith]

This is no longer required, implemented as part of D27406

ELF/OutputSections.cpp

template <class ELFT> void PltSection<ELFT>::writeTo(uint8_t *Buf) {
   Target->writePltHeader(Buf);
   size_t Off = Target->PltHeaderSize;
 
   for (auto &I : Entries) {
     const SymbolBody *B = I.first;
     unsigned RelOff = I.second;
     uint64_t Got = B->getGotPltVA<ELFT>();
     uint64_t Plt = this->getVA() + Off;
+    if (Config->EMachine == EM_ARM && B->isGnuIFunc() && !B->isPreemptible())
+      // ARM IRELATIVE relocations are in Rel.Dyn
+      Got = B->getGotVA<ELFT>();
     Target->writePlt(Buf + Off, Got, Plt, B->PltIndex, RelOff);
     Off += Target->PltEntrySize;
   }
 }
 
 template <class ELFT> void PltSection<ELFT>::addEntry(SymbolBody &Sym) {
   Sym.PltIndex = Entries.size();
   unsigned RelOff = Out<ELFT>::RelaPlt->getRelocOffset();

ELF/Relocations.cpp

if (needsPlt(Expr) || Expr == R_THUNK_ABS || Expr == R_THUNK_PC ||
       // relocation. We can process some of it and and just ask the dynamic
       // linker to add the load address.
       if (!Constant)
         AddDyn({Target->RelativeRel, &C, Offset, true, &Body, Addend});
 
       // If the produced value is a constant, we just remember to write it
       // when outputting this section. We also have to do it if the format
       // uses Elf_Rel, since in that case the written value is the addend.
-      if (Constant || !RelTy::IsRela)
+      if (Constant || !RelTy::IsRela ||
+          (Body.isGnuIFunc() && Config->EMachine == EM_ARM))
         C.Relocations.push_back({Expr, Type, Offset, Addend, &Body});
     } else {
       // We don't know anything about the finaly symbol. Just ask the dynamic
       // linker to handle the relocation for us.
       AddDyn({Target->getDynRel(Type), &C, Offset, false, &Body, Addend});
       // MIPS ABI turns using of GOT and dynamic relocations inside out.
       // While regular ABI uses dynamic relocations to fill up GOT entries
       // MIPS ABI requires dynamic linker to fills up GOT entries using
if (needsPlt(Expr)) {
       Out<ELFT>::Plt->addEntry(Body);
 
       uint32_t Rel;
       if (Body.isGnuIFunc() && !Preemptible)
         Rel = Target->IRelativeRel;
       else
         Rel = Target->PltRel;
 
+      if (Config->EMachine == EM_ARM && Rel == Target->IRelativeRel) {
+        Out<ELFT>::Got->addEntry(Body);
+        Out<ELFT>::RelaDyn->addReloc({Rel, Out<ELFT>::Got,
+                                      Body.getGotOffset<ELFT>(), !Preemptible,
+                                      &Body, 0});
+      } else {
         Out<ELFT>::GotPlt->addEntry(Body);
         Out<ELFT>::RelaPlt->addReloc({Rel, Out<ELFT>::GotPlt,
-                                    Body.getGotPltOffset<ELFT>(), !Preemptible,
-                                    &Body, 0});
+                                      Body.getGotPltOffset<ELFT>(),
+                                      !Preemptible, &Body, 0});
+      }
       continue;
     }
 
     if (refersToGotEntry(Expr)) {
       if (Config->EMachine == EM_MIPS) {
         // MIPS ABI has special rules to process GOT entries and doesn't
         // require relocation entries for them. A special case is TLS
         // relocations. In that case dynamic loader applies dynamic

ELF/Target.cpp

void ARMTargetInfo::writePltHeader(uint8_t *Buf) const {
   const uint8_t PltData[] = {
       0x04, 0xe0, 0x2d, 0xe5, //     str lr, [sp,#-4]!
       0x04, 0xe0, 0x9f, 0xe5, //     ldr lr, L2
       0x0e, 0xe0, 0x8f, 0xe0, // L1: add lr, pc, lr
       0x08, 0xf0, 0xbe, 0xe5, //     ldr pc, [lr, #8]
       0x00, 0x00, 0x00, 0x00, // L2: .word   &(.got.plt) - L1 - 8
   };
   memcpy(Buf, PltData, sizeof(PltData));
+  if (Out<ELF32LE>::GotPlt->empty())
+    write32le(Buf + 16, 0);
+  else {
     uint64_t GotPlt = Out<ELF32LE>::GotPlt->getVA();
     uint64_t L1 = Out<ELF32LE>::Plt->getVA() + 8;
     write32le(Buf + 16, GotPlt - L1 - 8);
   }
+}
 
 void ARMTargetInfo::writePlt(uint8_t *Buf, uint64_t GotEntryAddr,
                              uint64_t PltEntryAddr, int32_t Index,
                              unsigned RelOff) const {
   // FIXME: Using simple code sequence with simple relocations.
   // There is a more optimal sequence but it requires support for the group
   // relocations. See ELF for the ARM Architecture Appendix A.3
   const uint8_t PltData[] = {

ELF/Writer.cpp

 }
 
 // The beginning and the ending of .rel[a].plt section are marked
 // with __rel[a]_iplt_{start,end} symbols if it is a statically linked
 // executable. The runtime needs these symbols in order to resolve
 // all IRELATIVE relocs on startup. For dynamic executables, we don't
 // need these symbols, since IRELATIVE relocs are resolved through GOT
 // and PLT. For details, see http://www.airs.com/blog/archives/403.
+// On ARM the same symbols are used but the IRELATIVE relocations are in
+// .rel.dyn
 template <class ELFT> void Writer<ELFT>::addRelIpltSymbols() {
-  if (Out<ELFT>::DynSymTab || !Out<ELFT>::RelaPlt)
+  if (Out<ELFT>::DynSymTab || !Out<ELFT>::RelaPlt ||
+      (!Out<ELFT>::RelaDyn && Config->EMachine == EM_ARM))
     return;
   StringRef S = Config->Rela ? "__rela_iplt_start" : "__rel_iplt_start";
-  addOptionalSynthetic(S, Out<ELFT>::RelaPlt, 0);
+  addOptionalSynthetic(
+      S, (Config->EMachine == EM_ARM ? Out<ELFT>::RelaDyn : Out<ELFT>::RelaPlt),
+      0);
 
   S = Config->Rela ? "__rela_iplt_end" : "__rel_iplt_end";
-  addOptionalSynthetic(S, Out<ELFT>::RelaPlt,
-                       DefinedSynthetic<ELFT>::SectionEnd);
+  addOptionalSynthetic(
+      S, (Config->EMachine == EM_ARM ? Out<ELFT>::RelaDyn : Out<ELFT>::RelaPlt),
 }
 
 // The linker is expected to define some symbols depending on
 // the linking result. This function defines such symbols.
 template <class ELFT> void Writer<ELFT>::addReservedSymbols() {
   if (Config->EMachine == EM_MIPS && !Config->Relocatable) {
     // Define _gp for MIPS. st_value of _gp symbol will be updated by Writer
     // so that it points to an absolute address which is relative to GOT.
if (Out<ELFT>::RelaDyn->hasRelocs())
       Add(Out<ELFT>::RelaDyn);
     Add(Out<ELFT>::MipsRldMap);
   }
 
   // We always need to add rel[a].plt to output if it has entries.
   // Even during static linking it can contain R_[*]_IRELATIVE relocations.
   if (Out<ELFT>::RelaPlt && Out<ELFT>::RelaPlt->hasRelocs())
     Add(Out<ELFT>::RelaPlt);
+  // ARM puts R_ARM_IRELATIVE relocations in rel.dyn.
+  if (Config->EMachine == EM_ARM && !Out<ELFT>::DynSymTab &&
+      Out<ELFT>::RelaDyn && Out<ELFT>::RelaDyn->hasRelocs())
+    Add(Out<ELFT>::RelaDyn);
 
   if (needsGot())
     Add(Out<ELFT>::Got);
   if (Out<ELFT>::GotPlt && !Out<ELFT>::GotPlt->empty())
     Add(Out<ELFT>::GotPlt);
   if (!Out<ELFT>::Plt->empty())
     Add(Out<ELFT>::Plt);
   if (!Out<ELFT>::EhFrame->empty())

test/ELF/arm-gnu-ifunc.s

 // RUN: llvm-mc -filetype=obj -triple=armv7a-none-linux-gnueabi %s -o %t.o
 // RUN: ld.lld -static %t.o -o %tout
-// RUN: llvm-objdump -triple armv7a-none-linux-gnueabi -d %tout | FileCheck %s --check-prefix=DISASM
+// RUN: llvm-objdump -triple armv7a-none-linux-gnueabi -s -d %tout | FileCheck %s --check-prefix=DISASM
 // RUN: llvm-readobj -r -symbols -sections %tout | FileCheck %s
 // REQUIRES: arm
  .syntax unified
  .text
  .type foo STT_GNU_IFUNC
  .globl foo
 foo:
  bx lr
 
  .type bar STT_GNU_IFUNC
  .globl bar
 bar:
  bx lr
 
  .globl _start
 _start:
  bl foo
  bl bar
  movw r0,:lower16:__rel_iplt_start
  movt r0,:upper16:__rel_iplt_start
  movw r0,:lower16:__rel_iplt_end
  movt r0,:upper16:__rel_iplt_end
 
-// CHECK:      Sections [
-// CHECK:       Section {
-// CHECK:       Index: 1
-// CHECK-NEXT:  Name: .rel.plt
-// CHECK-NEXT:  Type: SHT_REL
-// CHECK-NEXT:  Flags [
-// CHECK-NEXT:    SHF_ALLOC
-// CHECK-NEXT:  ]
-// CHECK-NEXT:  Address: [[REL:.*]]
-// CHECK-NEXT:  Offset:
-// CHECK-NEXT:   Size: 16
-// CHECK-NEXT:   Link:
-// CHECK-NEXT:   Info:
-// CHECK-NEXT:   AddressAlignment: 4
-// CHECK-NEXT:   EntrySize: 8
-// CHECK-NEXT:  }
-// CHECK: Relocations [
-// CHECK-NEXT:  Section (1) .rel.plt {
-// CHECK-NEXT:    0x1200C R_ARM_IRELATIVE
-// CHECK-NEXT:    0x12010 R_ARM_IRELATIVE
-// CHECK-NEXT:  }
-// CHECK-NEXT:]
-// CHECK:  Symbols [
-// CHECK:   Symbol {
-// CHECK:         Name: __rel_iplt_end
-// CHECK-NEXT:    Value: 0x100E4
-// CHECK-NEXT:    Size: 0
-// CHECK-NEXT:    Binding: Local
-// CHECK-NEXT:    Type: None
-// CHECK-NEXT:    Other [
-// CHECK-NEXT:      STV_HIDDEN
-// CHECK-NEXT:    ]
-// CHECK-NEXT:    Section: .rel.plt
-// CHECK-NEXT:  }
-// CHECK-NEXT:  Symbol {
-// CHECK-NEXT:    Name: __rel_iplt_start
-// CHECK-NEXT:    Value: 0x100D4
-// CHECK-NEXT:    Size: 0
-// CHECK-NEXT:    Binding: Local
-// CHECK-NEXT:    Type: None
-// CHECK-NEXT:    Other [
-// CHECK-NEXT:      STV_HIDDEN
-// CHECK-NEXT:    ]
-// CHECK-NEXT:    Section: .rel.plt
-// CHECK-NEXT:  }
-// CHECK-NEXT:  Symbol {
-// CHECK-NEXT:    Name: _start (38)
-// CHECK-NEXT:    Value: 0x11008
-// CHECK-NEXT:    Size: 0
-// CHECK-NEXT:    Binding: Global
-// CHECK-NEXT:    Type: None
-// CHECK-NEXT:    Other:
-// CHECK-NEXT:    Section: .text
-// CHECK-NEXT:  }
-// CHECK-NEXT:  Symbol {
-// CHECK-NEXT:    Name: bar
-// CHECK-NEXT:    Value: 0x11004
-// CHECK-NEXT:    Size: 0
-// CHECK-NEXT:    Binding: Global
-// CHECK-NEXT:    Type: GNU_IFunc
-// CHECK-NEXT:    Other: 0
-// CHECK-NEXT:    Section: .text
-// CHECK-NEXT:  }
-// CHECK-NEXT:  Symbol {
-// CHECK-NEXT:    Name: foo
-// CHECK-NEXT:    Value: 0x11000
-// CHECK-NEXT:    Size: 0
-// CHECK-NEXT:    Binding: Global
-// CHECK-NEXT:    Type: GNU_IFunc
-// CHECK-NEXT:    Other: 0
-// CHECK-NEXT:    Section: .text
-// CHECK-NEXT:  }
+// CHECK:          Name: .rel.dyn
+// CHECK-NEXT:     Type: SHT_REL
+// CHECK-NEXT:     Flags [
+// CHECK-NEXT:       SHF_ALLOC
+// CHECK-NEXT:     ]
+// CHECK-NEXT:     Address: [[REL:.*]]
+// CHECK-NEXT:     Offset:
+// CHECK-NEXT:     Size: 16
+// CHECK-NEXT:     Link:
+// CHECK-NEXT:     Info:
+// CHECK-NEXT:     AddressAlignment: 4
+// CHECK-NEXT:     EntrySize: 8
+
+// CHECK:        Relocations [
+// CHECK-NEXT:   Section (1) .rel.dyn {
+// CHECK-NEXT:     0x12000 R_ARM_IRELATIVE
+// CHECK-NEXT:     0x12004 R_ARM_IRELATIVE
+
+// CHECK:        Name: __rel_iplt_end
+// CHECK-NEXT:     Value: 0x10104
+// CHECK-NEXT:     Size: 0
+// CHECK-NEXT:     Binding: Local
+// CHECK-NEXT:     Type: None
+// CHECK-NEXT:     Other [
+// CHECK-NEXT:       STV_HIDDEN
+// CHECK:         Name: __rel_iplt_start
+// CHECK-NEXT:     Value: 0x100F4
+// CHECK-NEXT:     Size: 0
+// CHECK-NEXT:     Binding: Local
+// CHECK-NEXT:     Type: None
+// CHECK-NEXT:     Other [
+// CHECK-NEXT:       STV_HIDDEN
 
-// DISASM:      Disassembly of section .text:
+// DISASM: Disassembly of section .text:
 // DISASM-NEXT: foo:
-// DISASM-NEXT:   11000:       1e ff 2f e1     bx      lr
-// DISASM: bar:
-// DISASM-NEXT:   11004:       1e ff 2f e1     bx      lr
-// DISASM: _start:
-// DISASM-NEXT:   11008:       09 00 00 eb     bl      #36
-// DISASM-NEXT:   1100c:       0c 00 00 eb     bl      #48
-// DISASM-NEXT:   11010:       d4 00 00 e3     movw    r0, #212
-// DISASM-NEXT:   11014:       01 00 40 e3     movt    r0, #1
-// r0 = 212 + 1 * 65536 = 100D4 = __rel_iplt_start
-// DISASM-NEXT:   11018:       e4 00 00 e3     movw    r0, #228
-// DISASM-NEXT:   1101c:       01 00 40 e3     movt    r0, #1
-// r1 = 228 + 1 * 65536 = 100E4 = __rel_iplt_end
-// DISASM-NEXT: Disassembly of section .plt:
+// DISASM-NEXT:    11000:       1e ff 2f e1     bx      lr
+// DISASM:      bar:
+// DISASM-NEXT:    11004:       1e ff 2f e1     bx      lr
+// DISASM:      _start:
+// DISASM-NEXT:    11008:       09 00 00 eb     bl      #36
+// DISASM-NEXT:    1100c:       0c 00 00 eb     bl      #48
+// DISASM-NEXT:    11010:       f4 00 00 e3     movw    r0, #244
+// DISASM-NEXT:    11014:       01 00 40 e3     movt    r0, #1
+// r0 = 224 + 1 * 65536 = 100F4 = __rel_iplt_start
+// DISASM-NEXT:    11018:       04 01 00 e3     movw    r0, #260
+// DISASM-NEXT:    1101c:       01 00 40 e3     movt    r0, #1
+// r0 = 260 + 1 * 65536 = 10104 = __rel_iplt_end
+// DISASM: Disassembly of section .plt:
 // DISASM-NEXT: .plt:
-// DISASM-NEXT:   11020:       04 e0 2d e5     str     lr, [sp, #-4]!
-// DISASM-NEXT:   11024:       04 e0 9f e5     ldr     lr, [pc, #4]
-// DISASM-NEXT:   11028:       0e e0 8f e0     add     lr, pc, lr
-// DISASM-NEXT:   1102c:       08 f0 be e5     ldr     pc, [lr, #8]!
-// 0x0fd0 + 0x11028 + 0x8 = 0x12000
-// DISASM-NEXT:   11030:       d0 0f 00 00
-// DISASM-NEXT:   11034:       04 c0 9f e5     ldr     r12, [pc, #4]
-// DISASM-NEXT:   11038:       0f c0 8c e0     add     r12, r12, pc
-// DISASM-NEXT:   1103c:       00 f0 9c e5     ldr     pc, [r12]
-// 0x0fcc + 0x11038 + 0x8 = 0x1200C
-// DISASM-NEXT:   11040:       cc 0f 00 00
-// DISASM-NEXT:   11044:       04 c0 9f e5     ldr     r12, [pc, #4]
-// DISASM-NEXT:   11048:       0f c0 8c e0     add     r12, r12, pc
-// DISASM-NEXT:   1104c:       00 f0 9c e5     ldr     pc, [r12]
-// 0x0fc0 + 0x11048 + 0x8 = 0x12010
-// DISASM-NEXT:   11050:       c0 0f 00 00
+// DISASM-NEXT:    11020:       04 e0 2d e5     str     lr, [sp, #-4]!
+// DISASM-NEXT:    11024:       04 e0 9f e5     ldr     lr, [pc, #4]
+// DISASM-NEXT:    11028:       0e e0 8f e0     add     lr, pc, lr
+// DISASM-NEXT:    1102c:       08 f0 be e5     ldr     pc, [lr, #8]!
+// DISASM-NEXT:    11030:       00 00 00 00
+// DISASM-NEXT:    11034:       04 c0 9f e5     ldr     r12, [pc, #4]
+// DISASM-NEXT:    11038:       0f c0 8c e0     add     r12, r12, pc
+// DISASM-NEXT:    1103c:       00 f0 9c e5     ldr     pc, [r12]
+// 11038 + 8 + fc0 = 12000 = GOT entry for foo
+// DISASM-NEXT:    11040:       c0 0f 00 00
+// DISASM-NEXT:    11044:       04 c0 9f e5     ldr     r12, [pc, #4]
+// DISASM-NEXT:    11048:       0f c0 8c e0     add     r12, r12, pc
+// DISASM-NEXT:    1104c:       00 f0 9c e5     ldr     pc, [r12]
+// 11048 + 8 + fb4 = 12004 = GOT entry for bar
+// DISASM-NEXT:    11050:       b4 0f 00 00
+
+// DISASM: Contents of section .got:
+// DISASM-NEXT:    12000 00100100 04100100