[all-commits] [llvm/llvm-project] d4d4c6: [llvm-objcopy] -O binary: skip empty sections

Fangrui Song via All-commits all-commits at lists.llvm.org
Fri May 1 20:43:32 PDT 2020


  Branch: refs/heads/release/10.x
  Home:   https://github.com/llvm/llvm-project
  Commit: d4d4c6bf834142326301a743d2939e868d9f0f0f
      https://github.com/llvm/llvm-project/commit/d4d4c6bf834142326301a743d2939e868d9f0f0f
  Author: Fangrui Song <maskray at google.com>
  Date:   2020-05-01 (Fri, 01 May 2020)

  Changed paths:
    M llvm/test/tools/llvm-objcopy/ELF/binary-paddr.test
    M llvm/tools/llvm-objcopy/ELF/Object.cpp

  Log Message:
  -----------
  [llvm-objcopy] -O binary: skip empty sections

After SHF_ALLOC sections are ordered by LMA:

* If initial sections are empty, GNU objcopy skips their contents while we
  emit leading zeros. (binary-paddr.test %t4)
* If trailing sections are empty, GNU objcopy skips their contents while we
  emit trailing zeros. (binary-paddr.test %t5)

This patch matches GNU objcopy's behavior. Linkers don't keep p_memsz
PT_LOAD segments. Such empty sections would not have a containing
PT_LOAD and `Section::ParentSegment` might be null if linkers fail to
optimize the file offsets (lld D79254).

In particular, without D79254, the arm Linux kernel's multi_v5_defconfig
depends on this behavior: in `vmlinux`, an empty .text_itcm is mapped at
a very high address (0xfffe0000) but the kernel does not expect
`objcopy -O binary` to create a very large `arch/arm/boot/Image`
(0xfffe0000-0xc0000000 ~= 1GiB). See https://bugs.llvm.org/show_bug.cgi?id=45632

Reviewed By: jhenderson

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

(cherry picked from commit ec786906f5feb4dceba1b5338927079e63e78095)




More information about the All-commits mailing list