llvm-project/lld
Fangrui Song 673e81eee4 [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
2020-03-30 10:03:55 -07:00
..
COFF [COFF] Stabilize sort 2020-03-28 21:38:50 +01:00
Common Replace MCTargetOptionsCommandFlags.inc and CommandFlags.inc by runtime registration 2020-03-17 14:01:30 +01:00
ELF [ELF] Allow SHF_LINK_ORDER and non-SHF_LINK_ORDER to be mixed 2020-03-30 10:03:55 -07:00
MinGW Remove unused Endian.h includes, NFC 2020-03-11 15:45:34 -07:00
cmake/modules
docs doc: use the right url to bugzilla 2020-03-22 22:49:40 +01:00
include/lld LLD already has a mechanism for caching creation of DWARCContext: 2020-03-06 21:17:07 +03:00
lib Make llvm::StringRef to std::string conversions explicit. 2020-01-28 23:25:25 +01:00
test [ELF] Allow SHF_LINK_ORDER and non-SHF_LINK_ORDER to be mixed 2020-03-30 10:03:55 -07:00
tools/lld [lld] Enabling loading LLVM pass plugins 2020-03-23 14:18:32 -07:00
unittests Make llvm::StringRef to std::string conversions explicit. 2020-01-28 23:25:25 +01:00
utils Python 2/3 compatibility 2019-03-20 07:42:13 +00:00
wasm [ThinLTO] Allow usage of all hardware threads in the system 2020-03-27 10:20:58 -04:00
.clang-format
.clang-tidy [lld] Add .clang-tidy to customize readability-identifier-naming.{Member,Parameter,Variable}Case => camelBack 2020-03-09 08:26:41 -07:00
.gitignore
CMakeLists.txt try to unbreak build after 4b6d9ac392 2020-01-16 10:12:35 -05:00
CODE_OWNERS.TXT
LICENSE.TXT Fix typos throughout the license files that somehow I and my reviewers 2019-01-21 09:52:34 +00:00
README.md

README.md

LLVM Linker (lld)

This directory and its subdirectories contain source code for the LLVM Linker, a modular cross platform linker which is built as part of the LLVM compiler infrastructure project.

lld is open source software. You may freely distribute it under the terms of the license agreement found in LICENSE.txt.

Benchmarking

In order to make sure various developers can evaluate patches over the same tests, we create a collection of self contained programs.

It is hosted at https://s3-us-west-2.amazonaws.com/linker-tests/lld-speed-test.tar.xz

The current sha256 is 10eec685463d5a8bbf08d77f4ca96282161d396c65bd97dc99dbde644a31610f.