[all-commits] [llvm/llvm-project] 673e81: [ELF] Allow SHF_LINK_ORDER and non-SHF_LINK_ORDER ...

Fangrui Song via All-commits all-commits at lists.llvm.org
Mon Mar 30 10:04:06 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 673e81eee4fa3ffa38736f1063e6c4fa2d9278b0
      https://github.com/llvm/llvm-project/commit/673e81eee4fa3ffa38736f1063e6c4fa2d9278b0
  Author: Fangrui Song <maskray at google.com>
  Date:   2020-03-30 (Mon, 30 Mar 2020)

  Changed paths:
    M lld/ELF/OutputSections.cpp
    M lld/ELF/Writer.cpp
    M lld/test/ELF/linkerscript/linkorder.s
    R lld/test/ELF/linkorder-err3.s

  Log Message:
  -----------
  [ELF] Allow SHF_LINK_ORDER and non-SHF_LINK_ORDER to be mixed

Currently, `error: incompatible section flags for .rodata` is reported
when we mix SHF_LINK_ORDER and non-SHF_LINK_ORDER sections in an output section.

This is overconstrained. This patch allows mixed flags with the
requirement that SHF_LINK_ORDER sections must be contiguous. Mixing
flags is used by Linux aarch64 (https://github.com/ClangBuiltLinux/linux/issues/953)

  .init.data : { ... KEEP(*(__patchable_function_entries)) ... }

When the integrated assembler is enabled, clang's -fpatchable-function-entry=N[,M]
implementation sets the SHF_LINK_ORDER flag (D72215) to fix a number of
garbage collection issues.

Strictly speaking, the ELF specification does not require contiguous
SHF_LINK_ORDER sections but for many current uses of SHF_LINK_ORDER like
.ARM.exidx/__patchable_function_entries there has been a requirement for
the sections to be contiguous on top of the requirements of the ELF
specification.

This patch also imposes one restriction: SHF_LINK_ORDER sections cannot
be separated by a symbol assignment or a BYTE command. Not allowing BYTE
is a natural extension that a non-SHF_LINK_ORDER cannot be a separator.
Symbol assignments can delimiter the contents of SHF_LINK_ORDER
sections.  Allowing SHF_LINK_ORDER sections across symbol assignments
(especially __start_/__stop_) can make things hard to explain. The
restriction should not be a problem for practical use cases.

Reviewed By: psmith

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




More information about the All-commits mailing list