[lld] Support copy relocations for TLS symbols

[jrtc27]

Summary

Previously, if Local Exec was used to access a symbol not in the
executable, we would error with "symol '<sym>' has no type". Instead, we
should emit a copy relocation using .tbss.

[jrtc27]

Note that, for both GCC and LLVM, the default model used for TLS variables in position-depedent code is LE even if extern, relying on TLS copy relocations. GCC explicitly mentions this in gcc/config/riscv/riscv.c with /* Since we support TLS copy relocs, non-PIC TLS accesses may all use LE. */, and LLVM says // Non-PIC TLS lowering should always use the LocalExec model. (although perhaps that should mention *why* this is ok). Hence this is needed in order to link some real-world code.

[MaskRay]

Note that, for both GCC and LLVM, the default model used for TLS variables in position-depedent code is LE even if extern, relying on TLS copy relocations.

So RISC-V is in its own camp here. I played with other architectures. All use Initial Exec (a GOT for TPREL) for extern TLS variables.

i386: R_386_TLS_IE
ARM: R_ARM_TLS_IE32
MIPS: R_MIPS_TLS_GOTTPREL
AArch64: R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC
PowerPC32: R_PPC_GOT_TPREL16
PowerPC64: R_PPC64_GOT_TPREL16_LO_DS

Can you refer to me notes/links about the decision choice? This looks to me a bad design.

[ruiu]

Copy relocation is a hack to allow non-PIC object files to be linked with DSOs. And it is a bit dangerous hack because people don't usually understand the exact semantics of the copy relocation and can make an ABI-breaking change without knowing it. I described the problem here: https://github.com/llvm/llvm-project/blob/master/lld/ELF/Relocations.cpp#L517-L558

Copy relocation also wastes a little bit of resource because for each copy relocation we'll have two copies of the same piece of data in memory.

Therefore, I believe that we should in general avoid copy relocations. So I'm inclined to just tell users what to do to avoid copy relocations rather than silently working around and hiding the issue. All users have to do is essentailly recompile object files with -fPIC, and that shouldn't be too hard.

What do you think?

[jrtc27]

I would agree that, for other architectures, not supporting copy relocations for TLS makes sense, and a world without copy relocations would be good. However, at the end of the day, this is what the RISC-V toolchains out there currently rely upon, and it would be very sad to force an incompatibility, especially since -fPIC introduces extra indirection in many cases that aren't needed, in particular because code generation has to assume symbol preemption. It does seem at least however that -fPIE yields the saner IE model again for both LLVM and GCC.... which begs the question why, as PIE vs non-PIE makes absolutely zero difference to the TLS addresses and semantics. I haven't yet found a discussion as to why this decision was made; the comment in the GCC source was the only reference I could even find that acknowledged this would require copy relocations. Ultimately, Clang+LLD can't currently be used to build FreeBSD as a result of this (nor can GCC+LLD), and telling people they can't use the default compiler mode that has always worked doesn't seem like the right answer; either LLVM and GCC need to stop forcing TLS copy relocations for position-dependent executables, or we need to support it here in LLD (or both...).

@palmer-dabbelt Do you have any comments about this?

[ruiu]

James, I'm sorry that I think I missed your second comment. So if gcc and clang uses LE model even for extern TLS variables, I agree with you that it's odd. They may have wanted to avoid the cost of more general access models, but because the linker is able to relax them, that shouldn't be a big problem.

[jrtc27]

What's strange is that TLS GD(/LD)/IE *don't* have linker relaxations currently even in BFD (and no R_RISCV_RELAX relocations are emitted since both compilers know it's not currently a relaxable sequence) despite RISC-V's love of linker relaxations for other things, so the model chosen at compile-time is set in stone. The only exception is that a 32-bit LE offset gets relaxed into a 12-bit LE offset when possible, but that's not changing the model. It really feels like they should have gone with IE and defined linker relaxations (something that even other architectures have here, albeit they pad with NOPs rather than deleting code) instead of this approach, but alas that's what we have.

[MaskRay]

In D70398#1751716, @jrtc27 wrote:

What's strange is that TLS GD(/LD)/IE *don't* have linker relaxations currently even in BFD (and no R_RISCV_RELAX relocations are emitted since both compilers know it's not currently a relaxable sequence) despite RISC-V's love of linker relaxations for other things, so the model chosen at compile-time is set in stone. The only exception is that a 32-bit LE offset gets relaxed into a 12-bit LE offset when possible, but that's not changing the model. It really feels like they should have gone with IE and defined linker relaxations (something that even other architectures have here, albeit they pad with NOPs rather than deleting code) instead of this approach, but alas that's what we have.

The ABI does not say about any relaxation: code sequences can not be changed but dynamic DTPMOD relocations can be omitted if applicable, e.g. https://sourceware.org/bugzilla/show_bug.cgi?id=24676 https://sourceware.org/bugzilla/show_bug.cgi?id=24673.

I think we should improve the current TLS ABI:

• Replace traditional General Dynamic and Local Dynamic with TLSDESC (https://github.com/riscv/riscv-elf-psabi-doc/issues/94). Define the relaxations to Initial Exec and Local Exec (in lld, R_RELAX_TLS_GD_TO_IE and R_RELAX_TLS_GD_TO_LE).
• Define how Initial Exec relaxes to Local Exec (in lld, R_RELAX_IE_TO_LE).

I made a comment on https://sourceware.org/bugzilla/show_bug.cgi?id=23825 . Rich Felker pointed out that https://github.com/riscv/riscv-gcc/pull/118, which is applicable on GCC 7,8 and 9, can disallow Local Exec for extern TLS variable accesses https://github.com/richfelker/musl-cross-make/commit/52527c462f255065bcb053f14a13b747a8a30005. So we have a simple GCC fix. If we can reach a consensus, I think we can drop this lld change (sorry but I feel that allowing this case seems really, really bad).

Created https://github.com/riscv/riscv-elf-psabi-doc/issues/122

[jrtc27]

I would suggest stepping back and looking at the whole picture. TLS is not special here; for normal globals, both code models also rely on copy relocations, and there are likely to be many more of those. If you think TLS copy relocations are bad then you should also be against using HI/LO and PCREL_HI/LO for extern symbols and require those to be indirected through the GOT.

[dalias]

Copy relocations are extremely bad, in all places. They waste memory, possibly massive amounts (e.g. const char libfoo_table[1<<24] = { ... }; in a library transforms from 16M of shared text to 16M of per-instance data), and they make the size of structures and arrays exported from shared libraries part of the ABI (precluding extending them at the end in future library versions). They should not be used anywhere, and the only historical reason they exist at all is that, prior to the existence of shared libraries, the existing ABIs on platforms at the time allowed absolute references to data objects embedded in program text. There is no good reason to allow this on new architectures not encumbered by such legacy ABIs, and certainly no reason to introduce it for TLS, where the extreme memory waste is not per-process but per-thread.

[dalias]

I'm pretty sure copy relocations would also interact really badly with STV_PROTECTED TLS objects - the shared library would be accessing its own copy via local-dynamic model while the main program would be accessing the copy it made through the copy relocation. While STV_PROTECTED has all sorts of problems, prior to the introduction of TLS copy relocations, it *did* work as intended for TLS, even if not for global data and functions.

[MaskRay]

TLS copy relocation requires cooperation from the dynamic loader. Just skimmed through several dynamic loader implementations:

• glibc: sysdeps/riscv/dl-machine.h support TLS copy relocations.
• musl: https://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c case REL_COPY: does not.
• FreeBSD ld.so: libexec/rtld-elf/riscv/reloc.c does not.

glibc ld.so copies the data from the shared object to the TLS image in the executable, but musl and FreeBSD ld.so do not. So even if lld supported TLS copy relocation, it would not work on them because the TLS image would not be properly initialized.

The discussion about the relaxation can be moved to https://github.com/riscv/riscv-elf-psabi-doc/issues/122 We are proposing extensions to the ABI and deprecating things, existing executables/shared objects linked against glibc can still work. binutils cannot simply drop the change because it still needs to support existing object files/archives for a while...

[ruiu]

I think I agree with dalias. I don't get a point to allow users to use copy relocations liberally for a new ISA/ABI like RISC-V, and it looks like it is a problem that we should fix compilers as soon as possible, rather than adopting the linker to what compilers emit at the moment. Even though I can see the reason why you wanted to add this to lld, I can also imagine that that would be a regrettable decision in the long term.

[jrtc27]

I think the fact that many runtime linkers out there don't handle it correctly is a pretty compelling reason in and of itself (but I agree that, being a new ABI, it should avoid introducing more copy relocations). The fact that GCC relies on this behaviour (which glibc and bfd correctly implement) but doesn't document it anywhere other than in the compiler source itself is worrying, since it leads to the situation we have now where binaries built by GCC+bfd for other systems (such as FreeBSD) may not run correctly, as they will copy garbage from early on in the mapping.

EDIT: I see the discussion linked by MaskRay has already reached the conclusion that GCC will stop emitting these. I will file a patch for LLVM to do the same if nobody beats me to it (relaxations can come later once they are finalised).

[MaskRay]

In D70398#1755440, @jrtc27 wrote:

I think the fact that many runtime linkers out there don't handle it correctly is a pretty compelling reason in and of itself (but I agree that, being a new ABI, it should avoid introducing more copy relocations). The fact that GCC relies on this behaviour (which glibc and bfd correctly implement) but doesn't document it anywhere other than in the compiler source itself is worrying, since it leads to the situation we have now where binaries built by GCC+bfd for other systems (such as FreeBSD) may not run correctly, as they will copy garbage from early on in the mapping.

I am also worried about defects in fait accomplis. (I can regret nothing but I didn't start watching RISC-V toolchain development earlier...) This issue has demonstrated again how an alternative implementation (libc, compiler, linker, binary utilities, etc) can be valuable by improving the design!

EDIT: I see the discussion linked by MaskRay has already reached the conclusion that GCC will stop emitting these. I will file a patch for LLVM to do the same if nobody beats me to it (relaxations can come later once they are finalised).

I wanted to do this, but you claimed this first. Go ahead:) Given the consensus that TLS copy relocation is a bad idea and newer toolchains do not need to support it, can be drop this patch?

[jrtc27]

In D70398#1756018, @MaskRay wrote:

In D70398#1755440, @jrtc27 wrote:

EDIT: I see the discussion linked by MaskRay has already reached the conclusion that GCC will stop emitting these. I will file a patch for LLVM to do the same if nobody beats me to it (relaxations can come later once they are finalised).

I wanted to do this, but you claimed this first. Go ahead:) Given the consensus that TLS copy relocation is a bad idea and newer toolchains do not need to support it, can be drop this patch?

Oh, yes, I intended to abandon this.

lld/ELF/Relocations.cpp

 static SmallSet<SharedSymbol *, 4> getSymbolsAt(SharedSymbol &ss) {
   using Elf_Sym = typename ELFT::Sym;
 
   SharedFile &file = ss.getFile();
 
   SmallSet<SharedSymbol *, 4> ret;
   for (const Elf_Sym &s : file.template getGlobalELFSyms<ELFT>()) {
     if (s.st_shndx == SHN_UNDEF || s.st_shndx == SHN_ABS ||
-        s.getType() == STT_TLS || s.st_value != ss.value)
+        (s.getType() == STT_TLS) != ss.isTls() ||
+        s.st_value != ss.value)
       continue;
     StringRef name = check(s.getName(file.getStringTable()));
     Symbol *sym = symtab->find(name);
     if (auto *alias = dyn_cast_or_null<SharedSymbol>(sym))
       ret.insert(alias);
   }
   return ret;
 }

 // define an accessor getV().
 template <class ELFT> static void addCopyRelSymbol(SharedSymbol &ss) {
   // Copy relocation against zero-sized symbol doesn't make sense.
   uint64_t symSize = ss.getSize();
   if (symSize == 0 || ss.alignment == 0)
     fatal("cannot create a copy relocation for symbol " + toString(ss));
 
   // See if this symbol is in a read-only segment. If so, preserve the symbol's
-  // memory protection by reserving space in the .bss.rel.ro section.
+  // memory protection by reserving space in the .bss.rel.ro section. For TLS
+  // symbols, .tbss can always be relro.
+  bool isTbss = ss.isTls();
   bool isRO = isReadOnly<ELFT>(ss);
   BssSection *sec =
-      make<BssSection>(isRO ? ".bss.rel.ro" : ".bss", symSize, ss.alignment);
-  OutputSection *osec = (isRO ? in.bssRelRo : in.bss)->getParent();
+      make<BssSection>(isTbss ? ".tbss" : isRO ? ".bss.rel.ro" : ".bss",
+                       symSize, ss.alignment, isTbss);
+  OutputSection *osec =
+      (isTbss ? in.tbss : isRO ? in.bssRelRo : in.bss)->getParent();
 
   // At this point, sectionBases has been migrated to sections. Append sec to
   // sections.
   if (osec->sectionCommands.empty() ||
       !isa<InputSectionDescription>(osec->sectionCommands.back()))
     osec->sectionCommands.push_back(make<InputSectionDescription>(""));
   auto *isd = cast<InputSectionDescription>(osec->sectionCommands.back());
   isd->sections.push_back(sec);
static void processRelocAux(InputSectionBase &sec, RelExpr expr, RelType type,
   // STT_OBJECT) and canonical PLT (for STT_FUNC).
   if (!config->shared) {
     if (!canDefineSymbolInExecutable(sym)) {
       errorOrWarn("cannot preempt symbol: " + toString(sym) +
                   getLocation(sec, sym, offset));
       return;
     }
 
-    if (sym.isObject()) {
+    if (sym.isObject() || sym.isTls()) {
       // Produce a copy relocation.
       if (auto *ss = dyn_cast<SharedSymbol>(&sym)) {
         if (!config->zCopyreloc)
           error("unresolvable relocation " + toString(type) +
                 " against symbol '" + toString(*ss) +
                 "'; recompile with -fPIC or remove '-z nocopyreloc'" +
                 getLocation(sec, sym, offset));
         addCopyRelSymbol<ELFT>(*ss);

lld/ELF/SyntheticSections.h

 
 private:
   uint8_t *hashBuf;
 };
 
 // BssSection is used to reserve space for copy relocations and common symbols.
 // We create three instances of this class for .bss, .bss.rel.ro and "COMMON",
 // that are used for writable symbols, read-only symbols and common symbols,
-// respectively.
+// respectively, and one instance for .tbss used for thread-local symbols.
 class BssSection final : public SyntheticSection {
 public:
-  BssSection(StringRef name, uint64_t size, uint32_t alignment);
+  BssSection(StringRef name, uint64_t size, uint32_t alignment,
+             bool isTbss = false);
   void writeTo(uint8_t *) override {
     llvm_unreachable("unexpected writeTo() call for SHT_NOBITS section");
   }
   bool isNeeded() const override { return size != 0; }
   size_t getSize() const override { return size; }
 
   static bool classof(const SectionBase *s) { return s->bss; }
   uint64_t size;

 }
 
 // Linker generated sections which can be used as inputs and are not specific to
 // a partition.
 struct InStruct {
   InputSection *armAttributes;
   BssSection *bss;
   BssSection *bssRelRo;
+  BssSection *tbss;
   GotSection *got;
   GotPltSection *gotPlt;
   IgotPltSection *igotPlt;
   PPC64LongBranchTargetSection *ppc64LongBranchTarget;
   MipsGotSection *mipsGot;
   MipsRldMapSection *mipsRldMap;
   SyntheticSection *partEnd;
   SyntheticSection *partIndex;

lld/ELF/SyntheticSections.cpp

void BuildIdSection::writeTo(uint8_t *buf) {
   hashBuf = buf + 16;
 }
 
 void BuildIdSection::writeBuildId(ArrayRef<uint8_t> buf) {
   assert(buf.size() == hashSize);
   memcpy(hashBuf, buf.data(), hashSize);
 }
 
-BssSection::BssSection(StringRef name, uint64_t size, uint32_t alignment)
-    : SyntheticSection(SHF_ALLOC | SHF_WRITE, SHT_NOBITS, alignment, name) {
+BssSection::BssSection(StringRef name, uint64_t size, uint32_t alignment,
+                       bool isTbss)
+    : SyntheticSection(isTbss ? SHF_ALLOC | SHF_WRITE | SHF_TLS
+                              : SHF_ALLOC | SHF_WRITE,
+                       SHT_NOBITS, alignment, name) {
   this->bss = true;
   this->size = size;
 }
 
 EhFrameSection::EhFrameSection()
     : SyntheticSection(SHF_ALLOC, SHT_PROGBITS, 1, ".eh_frame") {}
 
 // Search for an existing CIE record or create a new one.

lld/ELF/Writer.cpp

template <class ELFT> void createSyntheticSections() {
   // .data.rel.ro.bss so that we match in the .data.rel.ro output section.
   // This makes sure our relro is contiguous.
   bool hasDataRelRo =
       script->hasSectionsCommand && findSection(".data.rel.ro", 0);
   in.bssRelRo =
       make<BssSection>(hasDataRelRo ? ".data.rel.ro.bss" : ".bss.rel.ro", 0, 1);
   add(in.bssRelRo);
 
+  in.tbss = make<BssSection>(".tbss", 0, 1, /*isTbss=*/true);
+  add(in.tbss);
+
   // Add MIPS-specific sections.
   if (config->emachine == EM_MIPS) {
     if (!config->shared && config->hasDynSymTab) {
       in.mipsRldMap = make<MipsRldMapSection>();
       add(in.mipsRldMap);
     }
     if (auto *sec = MipsAbiFlagsSection<ELFT>::create())
       add(sec);
template <class ELFT> void Writer<ELFT>::finalizeSections() {
   }
 
   // Some symbols are defined in term of program headers. Now that we
   // have the headers, we can find out which sections they point to.
   setReservedSymbolSections();
 
   finalizeSynthetic(in.bss);
   finalizeSynthetic(in.bssRelRo);
+  finalizeSynthetic(in.tbss);
   finalizeSynthetic(in.symTabShndx);
   finalizeSynthetic(in.shStrTab);
   finalizeSynthetic(in.strTab);
   finalizeSynthetic(in.got);
   finalizeSynthetic(in.mipsGot);
   finalizeSynthetic(in.igotPlt);
   finalizeSynthetic(in.gotPlt);
   finalizeSynthetic(in.relaIplt);

lld/test/ELF/linkerscript/orphan-report.s

 ## Check --orphan-handling=error reports errors about orphans.
 # RUN: not ld.lld -shared --orphan-handling=error -o %t.out --script %t.script \
 # RUN:   %t.o 2>&1 -verbose  -error-limit=0 | FileCheck %s --check-prefix=REPORT
 # REPORT:      {{.*}}.o:(.text) is being placed in '.text'
 # REPORT-NEXT: {{.*}}.o:(.text.2) is being placed in '.text'
 # REPORT-NEXT: <internal>:(.comment) is being placed in '.comment'
 # REPORT-NEXT: <internal>:(.bss) is being placed in '.bss'
 # REPORT-NEXT: <internal>:(.bss.rel.ro) is being placed in '.bss.rel.ro'
+# REPORT-NEXT: <internal>:(.tbss) is being placed in '.tbss'
 # REPORT-NEXT: <internal>:(.dynsym) is being placed in '.dynsym'
 # REPORT-NEXT: <internal>:(.gnu.version) is being placed in '.gnu.version'
 # REPORT-NEXT: <internal>:(.gnu.version_r) is being placed in '.gnu.version_r'
 # REPORT-NEXT: <internal>:(.gnu.hash) is being placed in '.gnu.hash'
 # REPORT-NEXT: <internal>:(.hash) is being placed in '.hash'
 # REPORT-NEXT: <internal>:(.dynamic) is being placed in '.dynamic'
 # REPORT-NEXT: <internal>:(.dynstr) is being placed in '.dynstr'
 # REPORT-NEXT: <internal>:(.rela.dyn) is being placed in '.rela.dyn'

lld/test/ELF/riscv-tls-le-copy.s

+# REQUIRES: riscv
+# RUN: echo '.tbss; .globl a, b; a: .zero 4; .size a, 4; b: .zero 4; .size b, 4' > %t.s
+
+## Check that we correctly emit a copy relocation if using LE to access a
+## symbol not in the executable.
+
+# RUN: llvm-mc -filetype=obj -triple=riscv32 %s -o %t.32.o
+# RUN: llvm-mc -filetype=obj -triple=riscv32 %t.s -o %t1.32.o
+# RUN: ld.lld -shared -soname=t1.so %t1.32.o -o %t1.32.so
+# RUN: ld.lld %t.32.o %t1.32.so -o %t.32
+# RUN: llvm-readobj -S -r %t.32 | FileCheck --check-prefix=LE-SECREL %s
+# RUN: llvm-objdump -d %t.32 | FileCheck --check-prefix=LE-DUMP %s
+
+# RUN: llvm-mc -filetype=obj -triple=riscv64 %s -o %t.64.o
+# RUN: llvm-mc -filetype=obj -triple=riscv64 %t.s -o %t1.64.o
+# RUN: ld.lld -shared -soname=t1.so %t1.64.o -o %t1.64.so
+# RUN: ld.lld %t.64.o %t1.64.so -o %t.64
+# RUN: llvm-readobj -S -r %t.64 | FileCheck --check-prefix=LE-SECREL %s
+# RUN: llvm-objdump -d %t.64 | FileCheck --check-prefix=LE-DUMP %s
+
+# LE-SECREL:      Name: .tbss
+# LE-SECREL-NEXT: Type: SHT_NOBITS
+# LE-SECREL-NEXT: Flags [ (0x403)
+# LE-SECREL-NEXT:   SHF_ALLOC (0x2)
+# LE-SECREL-NEXT:   SHF_TLS (0x400)
+# LE-SECREL-NEXT:   SHF_WRITE (0x1)
+# LE-SECREL-NEXT: ]
+# LE-SECREL-NEXT: Address: 0x[[TBSS:.*]]
+# LE-SECREL-NEXT: Offset:
+# LE-SECREL-NEXT: Size: 8
+
+# LE-SECREL:      .rela.dyn {
+# LE-SECREL-NEXT:   0x[[TBSS]] R_RISCV_COPY a 0x0
+# LE-SECREL-NEXT:              R_RISCV_COPY b 0x0
+# LE-SECREL-NEXT: }
+
+# LE-DUMP:      lui a5, 0
+# LE-DUMP-NEXT: add a5, a5, tp
+# LE-DUMP-NEXT: sw a0, 0(a5)
+
+# LE-DUMP:      lui a5, 0
+# LE-DUMP-NEXT: add a5, a5, tp
+# LE-DUMP-NEXT: sw a0, 4(a5)
+
+lui a5, %tprel_hi(a)
+add a5, a5, tp, %tprel_add(a)
+sw a0, %tprel_lo(a)(a5)
+
+lui a5, %tprel_hi(b)
+add a5, a5, tp, %tprel_add(b)
+sw a0, %tprel_lo(b)(a5)

lld/test/ELF/shared.s

 // test that .hash is linked to .dynsym
 // CHECK:        Index: 2
 // CHECK-NEXT:   Name: .dynsym
 // CHECK-NEXT:   Type: SHT_DYNSYM
 // CHECK-NEXT:   Flags [
 // CHECK-NEXT:     SHF_ALLOC
 // CHECK-NEXT:   ]
 // CHECK-NEXT:   Address: [[DYNSYMADDR:.*]]
-// CHECK-NEXT:   Offset: 0x170
+// CHECK-NEXT:   Offset:
 // CHECK-NEXT:   Size:
 // CHECK-NEXT:   Link: [[DYNSTR:.*]]
 // CHECK-NEXT:   Info: 1
 // CHECK-NEXT:   AddressAlignment: 4
 // CHECK-NEXT:   EntrySize: 16
 // CHECK-NEXT:   SectionData (
 // CHECK-NEXT:     0000:
 // CHECK-NEXT:     0010:

 // CHECK-NEXT:     Size: 0
 // CHECK-NEXT:     Binding: Local
 // CHECK-NEXT:     Type: None
 // CHECK-NEXT:     Other: 0
 // CHECK-NEXT:     Section: Undefined
 // CHECK-NEXT:   }
 // CHECK-NEXT:   Symbol {
 // CHECK-NEXT:     Name: _DYNAMIC
-// CHECK-NEXT:     Value: 0x402210
+// CHECK-NEXT:     Value:
 // CHECK-NEXT:     Size: 0
 // CHECK-NEXT:     Binding: Local
 // CHECK-NEXT:     Type: None
 // CHECK-NEXT:     Other [ (0x2)
 // CHECK-NEXT:       STV_HIDDEN
 // CHECK-NEXT:     ]
 // CHECK-NEXT:     Section: .dynamic
 // CHECK-NEXT:   }
 // CHECK-NEXT:   Symbol {
 // CHECK-NEXT:     Name: _start
-// CHECK-NEXT:     Value: 0x401208
+// CHECK-NEXT:     Value:
 // CHECK-NEXT:     Size: 0
 // CHECK-NEXT:     Binding: Global
 // CHECK-NEXT:     Type: None
 // CHECK-NEXT:     Other: 0
 // CHECK-NEXT:     Section: .text
 // CHECK-NEXT:   }
 // CHECK-NEXT:   Symbol {
 // CHECK-NEXT:     Name: bar

 // CHECK-NEXT:     Size: 0
 // CHECK-NEXT:     Binding: Local
 // CHECK-NEXT:     Type: None
 // CHECK-NEXT:     Other: 0
 // CHECK-NEXT:     Section: Undefined
 // CHECK-NEXT:   }
 // CHECK-NEXT:   Symbol {
 // CHECK-NEXT:     Name: _start
-// CHECK-NEXT:     Value: 0x401208
+// CHECK-NEXT:     Value:
 // CHECK-NEXT:     Size: 0
 // CHECK-NEXT:     Binding: Global
 // CHECK-NEXT:     Type: Non
 // CHECK-NEXT:     Other: 0
 // CHECK-NEXT:     Section: .text
 // CHECK-NEXT:   }
 // CHECK-NEXT:   Symbol {
 // CHECK-NEXT:     Name: bar