[ELF] - Support COPY, INFO, OVERLAY output sections attributes.

[grimar]

Summary

This is PR36298.

(COPY), (INFO), (OVERLAY) all have the same effect:
section should be marked as non-allocatable.

(https://www.eecs.umich.edu/courses/eecs373/readings/Linker.pdf,
3.6.8.1 Output Section Type)

[peter.smith]

For what it is worth COPY and OVERLAY are used quite a bit in embedded systems. The Arm GCC Embedded toolchain linker scripts in the sample directory use COPY to reserve an area for the heap and stack https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

.heap (COPY):
	{
		__end__ = .;
		PROVIDE(end = .);
		*(.heap*)
		__HeapLimit = .;
	} > RAM

	/* .stack_dummy section doesn't contains any symbols. It is only
	 * used for linker to calculate size of stack sections, and assign
	 * values to stack symbols later */
	.stack_dummy (COPY):
	{
		*(.stack*)
	} > RAM

I'd be very happy to see COPY implemented.

[ruiu]

Why do you want them? Do you actually want to build "TianoCore UEFI" firmware with lld?

ELF/ScriptParser.cpp

621

can be -> is

622

or "(OVERLAY)"

("A, B, C" isn't grammatically correct.)

[ruiu]

I mean, for any language, if you google for some extremely minor feature of that language, I'm pretty sure that you can always find one. So the fact that you can find a use case on the internet isn't very convincing that we should support it.

[peter.smith]

In D43071#1002684, @ruiu wrote:

I mean, for any language, if you google for some extremely minor feature of that language, I'm pretty sure that you can always find one. So the fact that you can find a use case on the internet isn't very convincing that we should support it.

While these minor features are not used at all in a system sophisticated enough to run ELF files directly, I'd argue that at least COPY will be used heavily in embedded systems as placement of the heap and stack via symbols derived from linker script sections is a common idiom. Overlays are not so common these days but they still exist. It is true that we haven't got a large contingent of embedded developers using the Arm port, there are a few, but I'm hoping we don't scare them away.

[grimar]

In D43071#1002684, @ruiu wrote:

I mean, for any language, if you google for some extremely minor feature of that language, I'm pretty sure that you can always find one. So the fact that you can find a use case on the internet isn't very convincing that we should support it.

I inspected binutils bugtracker and found following issue:
https://sourceware.org/bugzilla/show_bug.cgi?id=20062

In short it was about that person was unable to use gold as a drop in replacement for bfd to link
UEFI. I was interested if LLD can do this. Previous experience showed that linking specific things,
like kernels can reveal unobvious issues. And I expect LLD should be able to link UEFI or other programs
or at least would be nice to know why not and document it in bugtracker.

We were thinking about implementing features like "INSERT AFTER/INSERT BEFORE" which are probably even
more specific, and "INFO" is too simple for implementation to ignore it when alternative is to report
"undefined symbol INFO" error what we do now which is just bogus and not user friendly.
(and somebeody can try to define INFO symbol it will be treated as address expression and we will link
it without errors.)

[grimar]

• Addressed review comments.

[ruiu]

LGTM

ELF/ScriptParser.cpp

626

beginning

ELF/LinkerScript.cpp

if (auto *Sec = dyn_cast<OutputSection>(Base)) {
 
       // Add input sections to an output section.
       for (InputSection *S : V)
         Sec->addSection(S);
 
       Sec->SectionIndex = I++;
       if (Sec->Noload)
         Sec->Type = SHT_NOBITS;
+      if (Sec->NonAlloc)
+        Sec->Flags &= ~(uint64_t)SHF_ALLOC;
     }
   }
   Ctx = nullptr;
 }
 
 static OutputSection *findByName(ArrayRef<BaseCommand *> Vec,
                                  StringRef Name) {
   for (BaseCommand *Base : Vec)

ELF/OutputSections.h

public:
   Expr SubalignExpr;
   std::vector<BaseCommand *> SectionCommands;
   std::vector<StringRef> Phdrs;
   llvm::Optional<uint32_t> Filler;
   ConstraintKind Constraint = ConstraintKind::NoConstraint;
   std::string Location;
   std::string MemoryRegionName;
   std::string LMARegionName;
+  bool NonAlloc = false;
   bool Noload = false;
 
   template <class ELFT> void finalize();
   template <class ELFT> void writeTo(uint8_t *Buf);
   template <class ELFT> void maybeCompress();
 
   void sort(std::function<int(InputSectionBase *S)> Order);
   void sortInitFini();

ELF/ScriptParser.cpp

 // https://sourceware.org/binutils/docs/ld/Output-Section-Data.html
 uint32_t ScriptParser::readFill() {
   expect("(");
   uint32_t V = parseFill(next());
   expect(")");
   return V;
 }
 
-// Reads an expression and/or the special directive "(NOLOAD)" for an
-// output section definition.
+// Reads an expression and/or the special directive for an output
+// section definition. Directive is one of following: "(NOLOAD)",
+// "(COPY)", "(INFO)" or "(OVERLAY)".
 //
 // An output section name can be followed by an address expression
-// and/or by "(NOLOAD)". This grammar is not LL(1) because "(" can be
-// interpreted as either the beginning of some expression or "(NOLOAD)".
+// and/or directive. This grammar is not LL(1) because "(" can be
+// interpreted as either the beginning of some expression or begining
+// of directive.
 //
 // https://sourceware.org/binutils/docs/ld/Output-Section-Address.html
 // https://sourceware.org/binutils/docs/ld/Output-Section-Type.html
 void ScriptParser::readSectionAddressType(OutputSection *Cmd) {
   if (consume("(")) {
     if (consume("NOLOAD")) {
       expect(")");
       Cmd->Noload = true;
       return;
     }
+    if (consume("COPY") || consume("INFO") || consume("OVERLAY")) {
+      expect(")");
+      Cmd->NonAlloc = true;
+      return;
+    }
     Cmd->AddrExpr = readExpr();
     expect(")");
   } else {
     Cmd->AddrExpr = readExpr();
   }
 
   if (consume("(")) {
     expect("NOLOAD");

test/ELF/linkerscript/info-section-type.s

+# REQUIRES: x86
+# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t.o
+
+## In this test we check that output section types such as
+## COPY, INFO and OVERLAY marks output section as non-allocatable.
+
+# RUN: echo "SECTIONS { .bar : { *(.foo) } };" > %t.script
+# RUN: ld.lld -o %t --script %t.script %t.o
+# RUN: llvm-readobj -sections %t | FileCheck %s --check-prefix=DEFAULT
+# DEFAULT:      Name: .bar
+# DEFAULT:      Type: SHT_PROGBITS
+# DEFAULT-NEXT: Flags [
+# DEFAULT-NEXT:   SHF_ALLOC
+# DEFAULT-NEXT: ]
+
+# RUN: echo "SECTIONS { .bar (COPY) : { *(.foo) } };" > %t.script
+# RUN: ld.lld -o %t --script %t.script %t.o
+# RUN: llvm-readobj -sections %t | FileCheck %s --check-prefix=NONALLOC
+# NONALLOC:      Name: .bar
+# NONALLOC:      Type: SHT_PROGBITS
+# NONALLOC-NEXT: Flags [
+# NONALLOC-NEXT: ]
+
+# RUN: echo "SECTIONS { .bar (INFO) : { *(.foo) } };" > %t.script
+# RUN: ld.lld -o %t --script %t.script %t.o
+# RUN: llvm-readobj -sections %t | FileCheck %s --check-prefix=NONALLOC
+
+# RUN: echo "SECTIONS { .bar (OVERLAY) : { *(.foo) } };" > %t.script
+# RUN: ld.lld -o %t --script %t.script %t.o
+# RUN: llvm-readobj -sections %t | FileCheck %s --check-prefix=NONALLOC
+
+.section .foo,"a",@progbits
+.zero 1