[all-commits] [llvm/llvm-project] ec2953: [ELF] Assign file offsets of non-SHF_ALLOC after S...

[Fangrui Song via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: ec29538af2e0886a65f479d6a533956a1c478132
      https://github.com/llvm/llvm-project/commit/ec29538af2e0886a65f479d6a533956a1c478132
  Author: Fangrui Song <i at maskray.me>
  Date:   2020-08-18 (Tue, 18 Aug 2020)

  Changed paths:
    M lld/ELF/LinkerScript.cpp
    M lld/ELF/Writer.cpp
    M lld/test/ELF/linkerscript/memory-region-alignment.test
    A lld/test/ELF/linkerscript/sections-nonalloc.s
    M lld/test/ELF/linkerscript/sections.s
    M lld/test/ELF/linkerscript/symbols-non-alloc.test

  Log Message:
  -----------
  [ELF] Assign file offsets of non-SHF_ALLOC after SHF_ALLOC and set sh_addr=0 to non-SHF_ALLOC

* GNU ld places non-SHF_ALLOC sections after SHF_ALLOC sections. This has the
  advantage that the file offsets of a non-SHF_ALLOC cannot be contained in
  a PT_LOAD. This patch matches the behavior.
* For non-SHF_ALLOC non-orphan sections, GNU ld may assign non-zero sh_addr and
  treat them similar to SHT_NOBITS (not advance location counter). This
  is an alternative approach to what we have done in D85100.
  By placing non-SHF_ALLOC sections at the end, we can drop special
  cases in createSection and findOrphanPos added by D85100.

  Different from GNU ld, we set sh_addr to 0 for non-SHF_ALLOC sections. 0
  arguably is better because non-SHF_ALLOC sections don't appear in the memory
  image.

ELF spec says:

> sh_addr - If the section will appear in the memory image of a process, this
> member gives the address at which the section's first byte should
> reside. Otherwise, the member contains 0.

D85100 appeared to take a detour. If we take a combined view on D85100 and this
patch, the overall complexity slightly increases (one more 3-line loop) and
compatibility with GNU ld improves.

The behavior we don't want to match is the special treatment of .symtab
.shstrtab .strtab: they can be matched in LLD but not in GNU ld.

Reviewed By: jhenderson, psmith

Differential Revision: https://reviews.llvm.org/D85867