[ELF] - Implemented PROVIDE linker script command.

[grimar]

Summary

Patch implements PROVIDE command. It is often used in scripts I saw.

Description of PROVIDE (taken from https://www.sourceware.org/binutils/docs-2.10/ld_3.html#SEC17):
In some cases, it is desirable for a linker script to define a symbol only if it is referenced and is not defined by any object included in the link. For example, traditional linkers defined the symbol etext'. However, ANSI C requires that the user be able to use etext' as a function name without encountering an error. The PROVIDE keyword may be used to define a symbol, such as `etext', only if it is referenced but not defined. The syntax is PROVIDE(symbol = expression).

[ruiu]

ELF/LinkerScript.cpp

255–261

I'd make the symbol table visible from the linker script in order to eliminate this plumbing between LinkerScript and Writer.

[grimar]

• Addressed review comments.

[• rafael]

test/ELF/linkerscript-provide.s

50

Are these symbols produced as absolute by bfd and gold?

It would be really nice if they could be produced with an output section and offset. The advantaged is that offsets can be computed earlier. With that some day we could cleanup relocation processing further by representing relocation target as OutputSection + Offset. That way we would not need enums just to select getVA, getGotVA, getPltVA, etc.

[grimar]

test/ELF/linkerscript-provide.s

50

bfd and gold disagree here:

PROVIDE (begin_ext = .);
.plus : 
{
 PROVIDE (begin_sec = .);
 *(.plus) 
 PROVIDE (end_sec = .);
}
PROVIDE (end_ext = .);

bfd:

 Symbol {
  Name: begin_ext (1)
  Value: 0x1000
  Size: 0
  Binding: Global (0x1)
  Type: None (0x0)
  Other: 0
  Section: .plus (0x1)
}
Symbol {
  Name: end_ext (18)
  Value: 0x1008
  Size: 0
  Binding: Global (0x1)
  Type: None (0x0)
  Other: 0
  Section: .plus (0x1)
}
Symbol {
  Name: end_sec (26)
  Value: 0x1008
  Size: 0
  Binding: Global (0x1)
  Type: None (0x0)
  Other: 0
  Section: .plus (0x1)
}
Symbol {
  Name: begin_sec (34)
  Value: 0x1000
  Size: 0
  Binding: Global (0x1)
  Type: None (0x0)
  Other: 0
  Section: .plus (0x1)
}

gold:

  Symbol {
  Name: begin_ext (8)
  Value: 0x1000
  Size: 0
  Binding: Global (0x1)
  Type: None (0x0)
  Other: 0
  Section: Absolute (0xFFF1)
}
Symbol {
  Name: begin_sec (18)
  Value: 0x1000
  Size: 0
  Binding: Global (0x1)
  Type: None (0x0)
  Other: 0
  Section: .plus (0x1)
}
Symbol {
  Name: end_ext (28)
  Value: 0x1008
  Size: 0
  Binding: Global (0x1)
  Type: None (0x0)
  Other: 0
  Section: Absolute (0xFFF1)
}
Symbol {
  Name: end_sec (36)
  Value: 0x1008
  Size: 0
  Binding: Global (0x1)
  Type: None (0x0)
  Other: 0
  Section: .plus (0x1)
}

[llvm-commits]

If at all possible my preference would be:

• Require PRODIVE to be in an unambiguous location: inside an

OutputSection definition.

• Produce DefinedSynthetic symbols for them so that the section is set

correctly.

Cheers,
Rafael

First will be incompatible with some existing bsd scripts, for example:
https://svnweb.freebsd.org/base/head/sys/conf/ldscript.amd64?view=markup
It has
PROVIDE (start_ctors = .);
..
PROVIDE (stop_ctors = .);
declared outside output sections definition.
Would it be acceptable to require that ?

George.

---

llvm-commits mailing list
[e-mail]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

[ruiu]

ELF/LinkerScript.cpp

224–227

Can you make SymbolTable a member of LinkerScript and directly call addAbsolute here? Then I think you can remove ElfSym<ELFT>::Provide.

[emaste]

First will be incompatible with some existing bsd scripts, for example:
https://svnweb.freebsd.org/base/head/sys/conf/ldscript.amd64?view=markup
It has
PROVIDE (start_ctors = .);
..
PROVIDE (stop_ctors = .);
declared outside output sections definition.
Would it be acceptable to require that ?

In the case of (at least) start_ctors and stop_ctors the script is more clear with them inside of the .ctors : { } so it's reasonable for FreeBSD to move them.

I do wonder how common this will be in practice across arbitrary 3rd party software (that does not have a vested interest in linking with lld), but it seems reasonable to proceed with Rafael's suggestion for now and revisit later if necessary.

[grimar]

• Addressed review comments.

Changed addAbsolute to addSynthetic as was suggested by Rafael. That allows to add provide symbols early without updating symbols values during assignaddress.
I introduced next limitation for that: provide expression can't be anything except assign location counter. i.e only "xxx = ." is valid. And since
only provides inside output description sections are now allowed, that helps to avoid storing symbols in array for futher modification.
And it still covers the needs of script files I saw, so it should be reasonable simplification.

[grimar]

ELF/LinkerScript.cpp

224–227

I think I can not directly call addAbsolute from LinkerScript::assignAddresses() because
would catch undefined symbol error then if symbol is referenced.
I need this symbols to be added before symbol resolution and that is why had to add
LinkerScript::createSymbols() method.

But I was able to get rid of ElfSym<ELFT>::Provide after addressing Rafael's suggestion, I also
added some limitations (please read latest patch changelist) that allows
to simplify the code.

[grimar]

• Reformated testcase.

[• rafael]

I think this is fine, but since it is linker script please wait for Rui's final check.

ELF/LinkerScript.cpp

188

Using ArrayRef is a nice independent cleanup. Please commit it first.

256

This only handles symbols at the start and end of output sections, right?

I guess that is a reasonable restriction for now. We can add support afterwards for recording an offset.

[ruiu]

ELF/LinkerScript.cpp

265–266

Move this inside the for loop to make their scopes as narrow as possible.

ELF/LinkerScript.h

52–55

ContentKind is very confusing and seems unnecessary. Why don't you process ProvideKind elements in assignAddresses? You should be able to define symbols using the current VA in the function.

[grimar]

ELF/LinkerScript.cpp

188

Done. r266978

256

Yes. And probably we will not need adding anything else here. I never saw in linkerscripts places where
PROVIDE inside output section description was attached to something different than end/start.

265–266

I can't do that.
SecName is used to keep what section we currently processing (addSynthetic requires section as argument).
Val value will change and is different for start of the section and end. And since ProvideKind can be
somewhere between/after ContentKind command, we should have that value already prepared, as
ProvideKind itself does not let know - is it start or end section symbol.

ELF/LinkerScript.h

52–55

In initial version of this patch, addAbsolute was used, now addSynthetic is. There is no need to save list of symbols and update values in assignAddresses anymore, as they are always attached to begin/end of output section. That is current restriction of the patch discussed above in comments.

Also:

1. Imagine sample script and code:

.global _start
_start:
  call used1;

SECTIONS
{
  .text :
    {
      PROVIDE (used1 = .);
      *(.text)
    }
}

If I not define symbols in createSymbols(), I`ll get undefined symbol error before reaching assignAddresses().

2. Imagine another script:

echo SECTIONS
{
  .text : 
  { 
    PROVIDE (beginText = .);
    *(.text)
    PROVIDE (endText = .);
    }
}

Commands list currently would be:

SectionKind
  ProvideKind 
    ContentKind
  ProvideKind

So all ProvideKinds that are before ContentKind are attached to the begin of section, others - to the end. ContentKind is used to actually move VA.

Without ContentKind it would be:

SectionKind
  ProvideKind 
  ProvideKind

How it is possible to know where is start/end provides then ? And when to move VA forward ?

[grimar]

• Rebase

[Wallbraker]

As I was reading this patch and comments I had some concerns about the different behavior between bfd and gold and that error messages would not provide enough information. The patch seem to address these concern so I'm happy with this patch.

Since I know too little about the lld source I don't dare to accept revision. But thanks for the great work!

PS: My use case for linker scripts is hobby osdev.

[grimar]

In D19190#407852, @Wallbraker wrote:

As I was reading this patch and comments I had some concerns about the different behavior between bfd and gold and that error messages would not provide enough information. The patch seem to address these concern so I'm happy with this patch.

Since I know too little about the lld source I don't dare to accept revision. But thanks for the great work!

PS: My use case for linker scripts is hobby osdev.

Thanks for feedback ! For usual errors in script we already report script line + column (D18699),
I think one day we will connect that error reporting system with expression evaluations code somehow, so
finding errors will be easier.

[ruiu]

ELF/LinkerScript.h

52–55

If it is currently hard to do to process PROVIDE command as we assign addresses to sections, then something is not right. The way we represent SECTIONS subcommands are probably inappropriate. Building a feature on top of the data structure will things more complicated. I'll fix this first.

[ruiu]

I spent half a day on poking around LinkerScript and Writer to figure out how to implement SECTIONS sub-commands nicely, and my conclusion is that the current code needs redesigning.

The current design is structurally hard to handle SECTIONS command because both Writer and LinkerScript have partial view of the sections being constructed. Writer creates output sections in Writer::createSections, and LinkerScript is barely involved with that process. However, if linker scripts are in use, then the constructed output sections are passed to LinkerScript to create symbols, layout sections while evaulating linker script expressions. It is hard to do it right because some information are lost between Writer and LinkerScript. It's not just hard to understand, but it also sets a limitation on what we can do with SECTIONS subcommands. For example, this patch can't handle expressions that appear in middle of an output section description. Adding a support for that would be at least tricky.

The right way I think is to make LinkerScript create output sections, instead of using Writer's createSections, if there is a SECTIONS command, so that LinkerScript controls everything about layout. In the new function, we should order sections *and* assign addresses at the same time. As long as sections sizes are fixed by then (this needs some refactoring as well), it should be doable. It is probably the cleanest and simplest way to handle SECTIONS command, as it is going to be a single pass and won't require any intermediate representation as we interpret SECTIONS sub-commands directly.

I'm going to explore this more.

[grimar]

In D19190#408584, @ruiu wrote:

I spent half a day on poking around LinkerScript and Writer to figure out how to implement SECTIONS sub-commands nicely, and my conclusion is that the current code needs redesigning.

The current design is structurally hard to handle SECTIONS command because both Writer and LinkerScript have partial view of the sections being constructed. Writer creates output sections in Writer::createSections, and LinkerScript is barely involved with that process. However, if linker scripts are in use, then the constructed output sections are passed to LinkerScript to create symbols, layout sections while evaulating linker script expressions. It is hard to do it right because some information are lost between Writer and LinkerScript. It's not just hard to understand, but it also sets a limitation on what we can do with SECTIONS subcommands. For example, this patch can't handle expressions that appear in middle of an output section description. Adding a support for that would be at least tricky.

The right way I think is to make LinkerScript create output sections, instead of using Writer's createSections, if there is a SECTIONS command, so that LinkerScript controls everything about layout. In the new function, we should order sections *and* assign addresses at the same time. As long as sections sizes are fixed by then (this needs some refactoring as well), it should be doable. It is probably the cleanest and simplest way to handle SECTIONS command, as it is going to be a single pass and won't require any intermediate representation as we interpret SECTIONS sub-commands directly.

I'm going to explore this more.

My vision is here: http://reviews.llvm.org/D19976

[emaste]

rL276398

[grimar]

rL276398

ELF/LinkerScript.h

 
 // Parses a linker script. Calling this function updates
 // Config and ScriptConfig.
 void readLinkerScript(MemoryBufferRef MB);
 
 class ScriptParser;
 template <class ELFT> class InputSectionBase;
 template <class ELFT> class OutputSectionBase;
+template <class ELFT> class SymbolTable;
 
 // This class represents each rule in SECTIONS command.
 class SectionRule {
 public:
   SectionRule(StringRef D, StringRef S, bool Keep)
       : Dest(D), Keep(Keep), SectionPattern(S) {}
 
   // Returns true if S should be in Dest section.
   template <class ELFT> bool match(InputSectionBase<ELFT> *S);
 
   StringRef Dest;
 
   // KEEP command saves unused sections even if --gc-sections is specified.
   bool Keep = false;
 
 private:
   StringRef SectionPattern;
 };
 
 // This enum represents what we can observe in SECTIONS tag of script:
-// ExprKind is a location counter change, like ". = . + 0x1000"
-// SectionKind is a description of output section, like ".data :..."
-enum SectionsCommandKind { ExprKind, SectionKind };
+// * ExprKind is a location counter change, like ". = . + 0x1000"
+// * SectionKind is a description of output section, like ".data :..."
+// * ContentKind is a content of output section, it helps to distinguish PROVIDE
+//   command before and after section content, first one should have address
+//   equal to address of output section, second points to location after that.
+// * ProvideKind is PROVIDE command.
+enum SectionsCommandKind { ExprKind, SectionKind, ContentKind, ProvideKind };
 
 struct SectionsCommand {
   SectionsCommandKind Kind;
   std::vector<StringRef> Expr;
-  StringRef SectionName;
+  StringRef Name;
 };
 
 // ScriptConfiguration holds linker script parse results.
 struct ScriptConfiguration {
   // SECTIONS commands.
   std::vector<SectionRule> Sections;
 
   // Section fill attribute for each section.

 template <class ELFT> class LinkerScript {
 public:
   StringRef getOutputSection(InputSectionBase<ELFT> *S);
   ArrayRef<uint8_t> getFiller(StringRef Name);
   bool isDiscarded(InputSectionBase<ELFT> *S);
   bool shouldKeep(InputSectionBase<ELFT> *S);
   void assignAddresses(ArrayRef<OutputSectionBase<ELFT> *> S);
   int compareSections(StringRef A, StringRef B);
+  void createSymbols(SymbolTable<ELFT> &Symtab,
+                     ArrayRef<OutputSectionBase<ELFT> *> Sections);
 
 private:
   uint32_t getSectionOrder(StringRef Name);
   SectionRule *find(InputSectionBase<ELFT> *S);
 
   ScriptConfiguration &Opt = *ScriptConfig;
 };
 

ELF/LinkerScript.cpp

 template <class ELFT>
 bool LinkerScript<ELFT>::shouldKeep(InputSectionBase<ELFT> *S) {
   SectionRule *R = find(S);
   return R && R->Keep;
 }
 
 template <class ELFT>
 static OutputSectionBase<ELFT> *
 findSection(ArrayRef<OutputSectionBase<ELFT> *> V, StringRef Name) {
   for (OutputSectionBase<ELFT> *Sec : V)
     if (Sec->getName() == Name)
       return Sec;
   return nullptr;
 }
 
 template <class ELFT>
 void LinkerScript<ELFT>::assignAddresses(
     ArrayRef<OutputSectionBase<ELFT> *> Sections) {
   typedef typename ELFT::uint uintX_t;
 
   // Orphan sections are sections present in the input files which
   // are not explicitly placed into the output file by the linker script.
   // We place orphan sections at end of file.
   // Other linkers places them using some heuristics as described in
   // https://sourceware.org/binutils/docs/ld/Orphan-Sections.html#Orphan-Sections.
   for (OutputSectionBase<ELFT> *Sec : Sections) {
     StringRef Name = Sec->getName();
-    if (getSectionOrder(Name) == (uint32_t)-1)
+    if (getSectionOrder(Name) == (uint32_t)-1) {
       Opt.Commands.push_back({SectionKind, {}, Name});
+      Opt.Commands.push_back({ContentKind, {}, Name});
+    }
   }
 
   // Assign addresses as instructed by linker script SECTIONS sub-commands.
   uintX_t ThreadBssOffset = 0;
   uintX_t VA =
       Out<ELFT>::ElfHeader->getSize() + Out<ELFT>::ProgramHeaders->getSize();
 
   for (SectionsCommand &Cmd : Opt.Commands) {
     if (Cmd.Kind == ExprKind) {
       VA = evaluate(Cmd.Expr, VA);
       continue;
     }
+    if (Cmd.Kind != ContentKind)
+      continue;
 
-    OutputSectionBase<ELFT> *Sec = findSection<ELFT>(Sections, Cmd.SectionName);
+    OutputSectionBase<ELFT> *Sec = findSection<ELFT>(Sections, Cmd.Name);
     if (!Sec)
       continue;
 
     if ((Sec->getFlags() & SHF_TLS) && Sec->getType() == SHT_NOBITS) {
       uintX_t TVA = VA + ThreadBssOffset;
       TVA = alignTo(TVA, Sec->getAlign());
       Sec->setVA(TVA);
       ThreadBssOffset = TVA - VA + Sec->getSize();
       continue;

 template <class ELFT>
 ArrayRef<uint8_t> LinkerScript<ELFT>::getFiller(StringRef Name) {
   auto I = Opt.Filler.find(Name);
   if (I == Opt.Filler.end())
     return {};
   return I->second;
 }
 
 template <class ELFT>
+void LinkerScript<ELFT>::createSymbols(
+    SymbolTable<ELFT> &Symtab, ArrayRef<OutputSectionBase<ELFT> *> Sections) {
+  typedef typename ELFT::uint uintX_t;
+  if (!Opt.DoLayout)
+    return;
+
+  // Currently we support only PROVIDE keywords inside
+  // output sections descriptions that are used to mark
+  // begin and end of the section.
+  StringRef SecName;
+  uintX_t Val;
+  for (SectionsCommand &Cmd : Opt.Commands) {
+    if (Cmd.Kind == SectionKind) {
+      SecName = Cmd.Name;
+      Val = 0;
+    } else if (Cmd.Kind == ContentKind) {
+      Val = DefinedSynthetic<ELFT>::SectionEnd;
+    }
+
+    if (Cmd.Kind != ProvideKind)
+      continue;
+
+    OutputSectionBase<ELFT> *Sec = findSection(Sections, SecName);
+    if (!Sec)
+      continue;
+
+    StringRef SymName = Cmd.Name;
+    if (SymbolBody *S = Symtab.find(SymName))
+      if (S->isUndefined())
+        Symtab.addSynthetic(SymName, *Sec, Val);
+  }
+}
+
+template <class ELFT>
 uint32_t LinkerScript<ELFT>::getSectionOrder(StringRef Name) {
   auto Begin = Opt.Commands.begin();
   auto End = Opt.Commands.end();
   auto I = std::find_if(Begin, End, [&](SectionsCommand &N) {
-    return N.Kind == SectionKind && N.SectionName == Name;
+    return N.Kind == SectionKind && N.Name == Name;
   });
   return I == End ? (uint32_t)-1 : (I - Begin);
 }
 
 // A compartor to sort output sections. Returns -1 or 1 if
 // A or B are mentioned in linker script. Otherwise, returns 0.
 template <class ELFT>
 int LinkerScript<ELFT>::compareSections(StringRef A, StringRef B) {
private:
   void readNothing() {}
   void readOutput();
   void readOutputArch();
   void readOutputFormat();
   void readSearchDir();
   void readSections();
 
   void readLocationCounterValue();
+  void readProvide();
   void readOutputSectionDescription();
   void readSectionPatterns(StringRef OutSec, bool Keep);
 
   const static StringMap<Handler> Cmd;
   ScriptConfiguration &Opt = *ScriptConfig;
   StringSaver Saver = {ScriptConfig->Alloc};
   bool IsUnderSysroot;
 };
void ScriptParser::readSearchDir() {
   expect(")");
 }
 
 void ScriptParser::readSections() {
   Opt.DoLayout = true;
   expect("{");
   while (!Error && !skip("}")) {
     StringRef Tok = peek();
+    if (Tok == "PROVIDE")
+      setError("PROVIDE outside section declaration not allowed");
+
     if (Tok == ".")
       readLocationCounterValue();
     else
       readOutputSectionDescription();
   }
 }
 
 void ScriptParser::readSectionPatterns(StringRef OutSec, bool Keep) {
   expect("(");
+  Opt.Commands.push_back({ContentKind, {}, OutSec});
   while (!Error && !skip(")"))
     Opt.Sections.emplace_back(OutSec, next(), Keep);
 }
 
 void ScriptParser::readLocationCounterValue() {
   expect(".");
   expect("=");
   Opt.Commands.push_back({ExprKind, {}, ""});
   SectionsCommand &Cmd = Opt.Commands.back();
   while (!Error) {
     StringRef Tok = next();
     if (Tok == ";")
       break;
     Cmd.Expr.push_back(Tok);
   }
   if (Cmd.Expr.empty())
     error("error in location counter expression");
 }
 
+void ScriptParser::readProvide() {
+  expect("(");
+  Opt.Commands.push_back({ProvideKind, {}, ""});
+  SectionsCommand &Cmd = Opt.Commands.back();
+  Cmd.Name = next();
+
+  expect("=");
+  while (!Error) {
+    StringRef Tok = next();
+    if (Tok == ")")
+      break;
+    Cmd.Expr.push_back(Tok);
+  }
+  expect(";");
+
+  if (Cmd.Expr.empty())
+    error("empty provide expression");
+  else if (Cmd.Expr[0] != "." || Cmd.Expr.size() > 1)
+    error("PROVIDE does not support expressions");
+}
+
 void ScriptParser::readOutputSectionDescription() {
   StringRef OutSec = next();
   Opt.Commands.push_back({SectionKind, {}, OutSec});
   expect(":");
   expect("{");
   while (!Error && !skip("}")) {
     StringRef Tok = next();
-    if (Tok == "*") {
+    if (Tok == "PROVIDE") {
+      readProvide();
+    } else if (Tok == "*") {
       readSectionPatterns(OutSec, false);
     } else if (Tok == "KEEP") {
       expect("(");
       next(); // Skip *
       readSectionPatterns(OutSec, true);
       expect(")");
     } else {
       setError("unknown command " + Tok);

ELF/Writer.cpp

template <class ELFT> void Writer<ELFT>::createSections() {
   // Even the author of gold doesn't remember why gold behaves that way.
   // https://sourceware.org/ml/binutils/2002-03/msg00360.html
   if (isOutputDynamic())
     Symtab.addSynthetic("_DYNAMIC", *Out<ELFT>::Dynamic, 0);
 
   // Define __rel[a]_iplt_{start,end} symbols if needed.
   addRelIpltSymbols();
 
+  Script<ELFT>::X->createSymbols(Symtab, OutputSections);
+
   if (Out<ELFT>::EhFrameHdr->Sec)
     Out<ELFT>::EhFrameHdr->Sec->finalize();
 
   // Scan relocations. This must be done after every symbol is declared so that
   // we can correctly decide if a dynamic relocation is needed.
   // Check size() each time to guard against .bss being created.
   for (unsigned I = 0; I < OutputSections.size(); ++I) {
     OutputSectionBase<ELFT> *Sec = OutputSections[I];

test/ELF/linkerscript-provide.s

+# REQUIRES: x86
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t
+
+## We do not support PROVIDE keyword outside
+## of output section declarations.
+# RUN: echo "SECTIONS \
+# RUN: { \
+# RUN:    PROVIDE (beginText = .); \
+# RUN:    .text : \
+# RUN:    { \
+# RUN:      *(.text) \
+# RUN:    } \
+# RUN: }" > %t.script
+# RUN: not ld.lld -o %t2 --script %t.script %t 2>&1 | FileCheck -check-prefix=ERR1 %s
+# ERR1: PROVIDE outside section declaration not allowed
+
+## We do not support PROVIDE keyword that
+## contains anything except assign of location counter.
+# RUN: echo "SECTIONS \
+# RUN: { \
+# RUN:    .text : \
+# RUN:    { \
+# RUN:      PROVIDE (beginText = . + 0x0); \
+# RUN:      *(.text) \
+# RUN:    } \
+# RUN: }" > %t.script
+# RUN: not ld.lld -o %t2 --script %t.script %t 2>&1 | FileCheck -check-prefix=ERR2 %s
+# ERR2: PROVIDE does not support expressions
+
+## Empty expression is a error.
+# RUN: echo "SECTIONS \
+# RUN: { \
+# RUN:    .text : \
+# RUN:    { \
+# RUN:      PROVIDE (beginText = ); \
+# RUN:      *(.text) \
+# RUN:    } \
+# RUN: }" > %t.script
+# RUN: not ld.lld -o %t2 --script %t.script %t 2>&1 | FileCheck -check-prefix=ERR3 %s
+# ERR3: empty provide expression
+
+## Check case with PROVIDE inside section description.
+# RUN: echo "SECTIONS \
+# RUN: { \
+# RUN:    .text : \
+# RUN:    { \
+# RUN:      PROVIDE (beginText = .); \
+# RUN:      *(.text) \
+# RUN:      PROVIDE (endText = .); \
+# RUN:    } \
+# RUN: }" > %t.script
+# RUN: ld.lld -o %t2 --script %t.script %t
+# RUN: llvm-readobj -sections -symbols %t2 | FileCheck %s
+# CHECK:       Sections [
+# CHECK:         Section {
+# CHECK:           Name: .text
+# CHECK-NEXT:      Type: SHT_PROGBITS
+# CHECK-NEXT:      Flags [
+# CHECK-NEXT:        SHF_ALLOC
+# CHECK-NEXT:        SHF_EXECINSTR
+# CHECK-NEXT:      ]
+# CHECK-NEXT:      Address: 0x[[ADDR:.*]]
+# CHECK-NEXT:      Offset:
+# CHECK-NEXT:      Size: 10
+# CHECK-NEXT:      Link: 0
+# CHECK-NEXT:      Info: 0
+# CHECK-NEXT:      AddressAlignment: 4
+# CHECK-NEXT:      EntrySize: 0
+# CHECK-NEXT:    }
+# CHECK:       Symbol {
+# CHECK:          Name: beginText
+# CHECK-NEXT:     Value: 0x[[ADDR]]
+# CHECK-NEXT:     Size: 0
+# CHECK-NEXT:     Binding: Local
+# CHECK-NEXT:     Type: None
+# CHECK-NEXT:     Other [
+# CHECK-NEXT:       STV_HIDDEN
+# CHECK-NEXT:     ]
+# CHECK-NEXT:     Section: .text
+# CHECK-NEXT:   }
+# CHECK-NEXT:   Symbol {
+# CHECK-NEXT:     Name: endText
+# CHECK-NEXT:     Value: 0x12A
+# CHECK-NEXT:     Size: 0
+# CHECK-NEXT:     Binding: Local
+# CHECK-NEXT:     Type: None
+# CHECK-NEXT:     Other [
+# CHECK-NEXT:       STV_HIDDEN
+# CHECK-NEXT:     ]
+# CHECK-NEXT:     Section: .text
+# CHECK-NEXT:   }
+
+.globl _start
+_start:
+  call beginText
+  call endText