[PATCH] D85100: [ELF] Allow sections after a non-allocable section to be covered by PT_LOAD

[James Henderson via Phabricator via llvm-commits]

jhenderson added a comment.

I'm just trying to make sure I've got this straight. Current LLD behaviour is to ignore linker script positioning of non-allocatable sections and put them after all allocatable sections, and this changes to placing them in the output in their requested position. If a program header were to cover these sections as a result of covering the allocatable sections either side of them, the normally non-alloc sections are given addresses to maintain the address space. Makes sense to me.

Do we have/need a test case for non-alloc between two sections which are in different segments, e.g:

  | PT_LOAD1 |           | PT_LOAD2 |
  | alloc1   | non-alloc | alloc2   |

I'd expect non-alloc to not be covered by the segment, as it doesn't need to be (though I could be convinced it does need to be).



================
Comment at: lld/ELF/Writer.cpp:1237
               std::vector<BaseCommand *>::iterator e) {
+  // To make the addresses of orphan sections not affected by non-allocable
+  // sections in the middle, place orphan non-allocable sections in the end.
----------------
I think the term is "non-allocatable".


================
Comment at: lld/ELF/Writer.cpp:1238
+  // To make the addresses of orphan sections not affected by non-allocable
+  // sections in the middle, place orphan non-allocable sections in the end.
   OutputSection *sec = cast<OutputSection>(*e);
----------------



================
Comment at: lld/test/ELF/linkerscript/compress-debug-sections-custom.s:3
 
+## NOTE GNU ld makes .debug_str and .debug_info allocable due to `. += 10`.
 # RUN: echo "SECTIONS { \
----------------



================
Comment at: lld/test/ELF/linkerscript/symbols-non-alloc.test:2-3
 # REQUIRES: x86
+## The address of a symbol assignment after a non-allocable section equals to
+## the end address of the section.
+
----------------



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85100/new/

https://reviews.llvm.org/D85100