2015-07-24 21:03:07 +00:00
|
|
|
//===- InputFiles.cpp -----------------------------------------------------===//
|
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2015-07-24 21:03:07 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "InputFiles.h"
|
2022-03-15 23:15:43 -07:00
|
|
|
#include "Config.h"
|
2022-02-07 21:53:34 -08:00
|
|
|
#include "DWARF.h"
|
[ELF] Implement Dependent Libraries Feature
This patch implements a limited form of autolinking primarily designed to allow
either the --dependent-library compiler option, or "comment lib" pragmas (
https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in
C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically
add the specified library to the link when processing the input file generated
by the compiler.
Currently this extension is unique to LLVM and LLD. However, care has been taken
to design this feature so that it could be supported by other ELF linkers.
The design goals were to provide:
- A simple linking model for developers to reason about.
- The ability to to override autolinking from the linker command line.
- Source code compatibility, where possible, with "comment lib" pragmas in other
environments (MSVC in particular).
Dependent library support is implemented differently for ELF platforms than on
the other platforms. Primarily this difference is that on ELF we pass the
dependent library specifiers directly to the linker without manipulating them.
This is in contrast to other platforms where they are mapped to a specific
linker option by the compiler. This difference is a result of the greater
variety of ELF linkers and the fact that ELF linkers tend to handle libraries in
a more complicated fashion than on other platforms. This forces us to defer
handling the specifiers to the linker.
In order to achieve a level of source code compatibility with other platforms
we have restricted this feature to work with libraries that meet the following
"reasonable" requirements:
1. There are no competing defined symbols in a given set of libraries, or
if they exist, the program owner doesn't care which is linked to their
program.
2. There may be circular dependencies between libraries.
The binary representation is a mergeable string section (SHF_MERGE,
SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES
(0x6fff4c04). The compiler forms this section by concatenating the arguments of
the "comment lib" pragmas and --dependent-library options in the order they are
encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs
sections with the normal mergeable string section rules. As an example, #pragma
comment(lib, "foo") would result in:
.section ".deplibs","MS",@llvm_dependent_libraries,1
.asciz "foo"
For LTO, equivalent information to the contents of a the .deplibs section can be
retrieved by the LLD for bitcode input files.
LLD processes the dependent library specifiers in the following way:
1. Dependent libraries which are found from the specifiers in .deplibs sections
of relocatable object files are added when the linker decides to include that
file (which could itself be in a library) in the link. Dependent libraries
behave as if they were appended to the command line after all other options. As
a consequence the set of dependent libraries are searched last to resolve
symbols.
2. It is an error if a file cannot be found for a given specifier.
3. Any command line options in effect at the end of the command line parsing apply
to the dependent libraries, e.g. --whole-archive.
4. The linker tries to add a library or relocatable object file from each of the
strings in a .deplibs section by; first, handling the string as if it was
specified on the command line; second, by looking for the string in each of the
library search paths in turn; third, by looking for a lib<string>.a or
lib<string>.so (depending on the current mode of the linker) in each of the
library search paths.
5. A new command line option --no-dependent-libraries tells LLD to ignore the
dependent libraries.
Rationale for the above points:
1. Adding the dependent libraries last makes the process simple to understand
from a developers perspective. All linkers are able to implement this scheme.
2. Error-ing for libraries that are not found seems like better behavior than
failing the link during symbol resolution.
3. It seems useful for the user to be able to apply command line options which
will affect all of the dependent libraries. There is a potential problem of
surprise for developers, who might not realize that these options would apply
to these "invisible" input files; however, despite the potential for surprise,
this is easy for developers to reason about and gives developers the control
that they may require.
4. This algorithm takes into account all of the different ways that ELF linkers
find input files. The different search methods are tried by the linker in most
obvious to least obvious order.
5. I considered adding finer grained control over which dependent libraries were
ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this
is not necessary: if finer control is required developers can fall back to using
the command line directly.
RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html.
Differential Revision: https://reviews.llvm.org/D60274
llvm-svn: 360984
2019-05-17 03:44:15 +00:00
|
|
|
#include "Driver.h"
|
2016-02-11 15:24:48 +00:00
|
|
|
#include "InputSection.h"
|
2016-08-12 19:56:57 +00:00
|
|
|
#include "LinkerScript.h"
|
ELF: New symbol table design.
This patch implements a new design for the symbol table that stores
SymbolBodies within a memory region of the Symbol object. Symbols are mutated
by constructing SymbolBodies in place over existing SymbolBodies, rather
than by mutating pointers. As mentioned in the initial proposal [1], this
memory layout helps reduce the cache miss rate by improving memory locality.
Performance numbers:
old(s) new(s)
Without debug info:
chrome 7.178 6.432 (-11.5%)
LLVMgold.so 0.505 0.502 (-0.5%)
clang 0.954 0.827 (-15.4%)
llvm-as 0.052 0.045 (-15.5%)
With debug info:
scylla 5.695 5.613 (-1.5%)
clang 14.396 14.143 (-1.8%)
Performance counter results show that the fewer required indirections is
indeed the cause of the improved performance. For example, when linking
chrome, stalled cycles decreases from 14,556,444,002 to 12,959,238,310, and
instructions per cycle increases from 0.78 to 0.83. We are also executing
many fewer instructions (15,516,401,933 down to 15,002,434,310), probably
because we spend less time allocating SymbolBodies.
The new mechanism by which symbols are added to the symbol table is by calling
add* functions on the SymbolTable.
In this patch, I handle local symbols by storing them inside "unparented"
SymbolBodies. This is suboptimal, but if we do want to try to avoid allocating
these SymbolBodies, we can probably do that separately.
I also removed a few members from the SymbolBody class that were only being
used to pass information from the input file to the symbol table.
This patch implements the new design for the ELF linker only. I intend to
prepare a similar patch for the COFF linker.
[1] http://lists.llvm.org/pipermail/llvm-dev/2016-April/098832.html
Differential Revision: http://reviews.llvm.org/D19752
llvm-svn: 268178
2016-05-01 04:55:03 +00:00
|
|
|
#include "SymbolTable.h"
|
2015-07-24 21:03:07 +00:00
|
|
|
#include "Symbols.h"
|
2016-12-14 10:36:12 +00:00
|
|
|
#include "SyntheticSections.h"
|
2022-02-01 09:53:28 -08:00
|
|
|
#include "Target.h"
|
2022-01-20 14:53:18 -05:00
|
|
|
#include "lld/Common/CommonLinkerContext.h"
|
2019-11-14 14:16:21 -08:00
|
|
|
#include "lld/Common/DWARF.h"
|
2022-02-07 21:53:34 -08:00
|
|
|
#include "llvm/ADT/CachedHashString.h"
|
2015-07-24 21:03:07 +00:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2016-09-29 00:40:08 +00:00
|
|
|
#include "llvm/LTO/LTO.h"
|
2022-02-07 21:53:34 -08:00
|
|
|
#include "llvm/Object/IRObjectFile.h"
|
2017-11-28 13:51:48 +00:00
|
|
|
#include "llvm/Support/ARMAttributeParser.h"
|
|
|
|
#include "llvm/Support/ARMBuildAttributes.h"
|
2019-06-05 03:04:46 +00:00
|
|
|
#include "llvm/Support/Endian.h"
|
2022-02-07 21:53:34 -08:00
|
|
|
#include "llvm/Support/FileSystem.h"
|
2016-09-08 21:18:38 +00:00
|
|
|
#include "llvm/Support/Path.h"
|
2020-08-20 18:10:18 +01:00
|
|
|
#include "llvm/Support/RISCVAttributeParser.h"
|
2024-06-20 17:41:35 +02:00
|
|
|
#include "llvm/Support/TimeProfiler.h"
|
2016-02-12 20:54:57 +00:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2023-12-06 15:18:46 -08:00
|
|
|
#include <optional>
|
2015-07-24 21:03:07 +00:00
|
|
|
|
2015-09-04 22:28:10 +00:00
|
|
|
using namespace llvm;
|
2015-07-24 21:03:07 +00:00
|
|
|
using namespace llvm::ELF;
|
2015-09-03 20:03:54 +00:00
|
|
|
using namespace llvm::object;
|
2017-12-23 17:21:39 +00:00
|
|
|
using namespace llvm::sys;
|
2015-09-30 17:06:09 +00:00
|
|
|
using namespace llvm::sys::fs;
|
2019-06-05 03:04:46 +00:00
|
|
|
using namespace llvm::support::endian;
|
2020-05-14 22:18:58 -07:00
|
|
|
using namespace lld;
|
|
|
|
using namespace lld::elf;
|
|
|
|
|
2024-02-13 18:31:32 -05:00
|
|
|
// This function is explicitly instantiated in ARM.cpp, don't do it here to
|
|
|
|
// avoid warnings with MSVC.
|
2023-10-03 10:12:09 -04:00
|
|
|
extern template void ObjFile<ELF32LE>::importCmseSymbols();
|
|
|
|
extern template void ObjFile<ELF32BE>::importCmseSymbols();
|
|
|
|
extern template void ObjFile<ELF64LE>::importCmseSymbols();
|
|
|
|
extern template void ObjFile<ELF64BE>::importCmseSymbols();
|
|
|
|
|
2019-10-07 08:31:18 +00:00
|
|
|
// Returns "<internal>", "foo.a(bar.o)" or "baz.o".
|
2024-11-16 11:58:10 -08:00
|
|
|
std::string elf::toStr(Ctx &ctx, const InputFile *f) {
|
2022-08-06 01:00:06 -07:00
|
|
|
static std::mutex mu;
|
2019-10-07 08:31:18 +00:00
|
|
|
if (!f)
|
|
|
|
return "<internal>";
|
2015-07-24 21:03:07 +00:00
|
|
|
|
2022-08-06 01:00:06 -07:00
|
|
|
{
|
|
|
|
std::lock_guard<std::mutex> lock(mu);
|
|
|
|
if (f->toStringCache.empty()) {
|
|
|
|
if (f->archiveName.empty())
|
|
|
|
f->toStringCache = f->getName();
|
|
|
|
else
|
|
|
|
(f->archiveName + "(" + f->getName() + ")").toVector(f->toStringCache);
|
|
|
|
}
|
2019-10-07 08:31:18 +00:00
|
|
|
}
|
2021-12-14 20:55:32 -08:00
|
|
|
return std::string(f->toStringCache);
|
2019-10-07 08:31:18 +00:00
|
|
|
}
|
|
|
|
|
2024-11-06 08:25:58 -08:00
|
|
|
const ELFSyncStream &elf::operator<<(const ELFSyncStream &s,
|
|
|
|
const InputFile *f) {
|
2024-11-16 11:58:10 -08:00
|
|
|
return s << toStr(s.ctx, f);
|
2024-11-06 08:25:58 -08:00
|
|
|
}
|
|
|
|
|
2024-11-14 23:04:18 -08:00
|
|
|
static ELFKind getELFKind(Ctx &ctx, MemoryBufferRef mb, StringRef archiveName) {
|
2019-05-27 07:26:13 +00:00
|
|
|
unsigned char size;
|
|
|
|
unsigned char endian;
|
|
|
|
std::tie(size, endian) = getElfArchType(mb.getBuffer());
|
[Coding style change] Rename variables so that they start with a lowercase letter
This patch is mechanically generated by clang-llvm-rename tool that I wrote
using Clang Refactoring Engine just for creating this patch. You can see the
source code of the tool at https://reviews.llvm.org/D64123. There's no manual
post-processing; you can generate the same patch by re-running the tool against
lld's code base.
Here is the main discussion thread to change the LLVM coding style:
https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html
In the discussion thread, I proposed we use lld as a testbed for variable
naming scheme change, and this patch does that.
I chose to rename variables so that they are in camelCase, just because that
is a minimal change to make variables to start with a lowercase letter.
Note to downstream patch maintainers: if you are maintaining a downstream lld
repo, just rebasing ahead of this commit would cause massive merge conflicts
because this patch essentially changes every line in the lld subdirectory. But
there's a remedy.
clang-llvm-rename tool is a batch tool, so you can rename variables in your
downstream repo with the tool. Given that, here is how to rebase your repo to
a commit after the mass renaming:
1. rebase to the commit just before the mass variable renaming,
2. apply the tool to your downstream repo to mass-rename variables locally, and
3. rebase again to the head.
Most changes made by the tool should be identical for a downstream repo and
for the head, so at the step 3, almost all changes should be merged and
disappear. I'd expect that there would be some lines that you need to merge by
hand, but that shouldn't be too many.
Differential Revision: https://reviews.llvm.org/D64121
llvm-svn: 365595
2019-07-10 05:00:37 +00:00
|
|
|
|
2019-07-03 06:11:50 +00:00
|
|
|
auto report = [&](StringRef msg) {
|
2019-05-27 07:26:13 +00:00
|
|
|
StringRef filename = mb.getBufferIdentifier();
|
|
|
|
if (archiveName.empty())
|
2024-11-06 21:17:26 -08:00
|
|
|
Fatal(ctx) << filename << ": " << msg;
|
2019-05-27 07:26:13 +00:00
|
|
|
else
|
2024-11-06 21:17:26 -08:00
|
|
|
Fatal(ctx) << archiveName << "(" << filename << "): " << msg;
|
2019-05-27 07:26:13 +00:00
|
|
|
};
|
|
|
|
|
2023-06-05 14:36:19 -07:00
|
|
|
if (!mb.getBuffer().starts_with(ElfMagic))
|
2019-07-03 06:11:50 +00:00
|
|
|
report("not an ELF file");
|
2019-05-27 07:26:13 +00:00
|
|
|
if (endian != ELFDATA2LSB && endian != ELFDATA2MSB)
|
2019-07-03 06:11:50 +00:00
|
|
|
report("corrupted ELF file: invalid data encoding");
|
2019-05-27 07:26:13 +00:00
|
|
|
if (size != ELFCLASS32 && size != ELFCLASS64)
|
2019-07-03 06:11:50 +00:00
|
|
|
report("corrupted ELF file: invalid file class");
|
[Coding style change] Rename variables so that they start with a lowercase letter
This patch is mechanically generated by clang-llvm-rename tool that I wrote
using Clang Refactoring Engine just for creating this patch. You can see the
source code of the tool at https://reviews.llvm.org/D64123. There's no manual
post-processing; you can generate the same patch by re-running the tool against
lld's code base.
Here is the main discussion thread to change the LLVM coding style:
https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html
In the discussion thread, I proposed we use lld as a testbed for variable
naming scheme change, and this patch does that.
I chose to rename variables so that they are in camelCase, just because that
is a minimal change to make variables to start with a lowercase letter.
Note to downstream patch maintainers: if you are maintaining a downstream lld
repo, just rebasing ahead of this commit would cause massive merge conflicts
because this patch essentially changes every line in the lld subdirectory. But
there's a remedy.
clang-llvm-rename tool is a batch tool, so you can rename variables in your
downstream repo with the tool. Given that, here is how to rebase your repo to
a commit after the mass renaming:
1. rebase to the commit just before the mass variable renaming,
2. apply the tool to your downstream repo to mass-rename variables locally, and
3. rebase again to the head.
Most changes made by the tool should be identical for a downstream repo and
for the head, so at the step 3, almost all changes should be merged and
disappear. I'd expect that there would be some lines that you need to merge by
hand, but that shouldn't be too many.
Differential Revision: https://reviews.llvm.org/D64121
llvm-svn: 365595
2019-07-10 05:00:37 +00:00
|
|
|
|
2019-05-27 07:26:13 +00:00
|
|
|
size_t bufSize = mb.getBuffer().size();
|
|
|
|
if ((size == ELFCLASS32 && bufSize < sizeof(Elf32_Ehdr)) ||
|
|
|
|
(size == ELFCLASS64 && bufSize < sizeof(Elf64_Ehdr)))
|
2019-07-03 06:11:50 +00:00
|
|
|
report("corrupted ELF file: file is too short");
|
[Coding style change] Rename variables so that they start with a lowercase letter
This patch is mechanically generated by clang-llvm-rename tool that I wrote
using Clang Refactoring Engine just for creating this patch. You can see the
source code of the tool at https://reviews.llvm.org/D64123. There's no manual
post-processing; you can generate the same patch by re-running the tool against
lld's code base.
Here is the main discussion thread to change the LLVM coding style:
https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html
In the discussion thread, I proposed we use lld as a testbed for variable
naming scheme change, and this patch does that.
I chose to rename variables so that they are in camelCase, just because that
is a minimal change to make variables to start with a lowercase letter.
Note to downstream patch maintainers: if you are maintaining a downstream lld
repo, just rebasing ahead of this commit would cause massive merge conflicts
because this patch essentially changes every line in the lld subdirectory. But
there's a remedy.
clang-llvm-rename tool is a batch tool, so you can rename variables in your
downstream repo with the tool. Given that, here is how to rebase your repo to
a commit after the mass renaming:
1. rebase to the commit just before the mass variable renaming,
2. apply the tool to your downstream repo to mass-rename variables locally, and
3. rebase again to the head.
Most changes made by the tool should be identical for a downstream repo and
for the head, so at the step 3, almost all changes should be merged and
disappear. I'd expect that there would be some lines that you need to merge by
hand, but that shouldn't be too many.
Differential Revision: https://reviews.llvm.org/D64121
llvm-svn: 365595
2019-07-10 05:00:37 +00:00
|
|
|
|
2019-05-27 07:26:13 +00:00
|
|
|
if (size == ELFCLASS32)
|
|
|
|
return (endian == ELFDATA2LSB) ? ELF32LEKind : ELF32BEKind;
|
|
|
|
return (endian == ELFDATA2LSB) ? ELF64LEKind : ELF64BEKind;
|
|
|
|
}
|
|
|
|
|
2022-08-03 21:49:17 -07:00
|
|
|
// For ARM only, to set the EF_ARM_ABI_FLOAT_SOFT or EF_ARM_ABI_FLOAT_HARD
|
|
|
|
// flag in the ELF Header we need to look at Tag_ABI_VFP_args to find out how
|
|
|
|
// the input objects have been compiled.
|
2024-10-03 23:06:18 -07:00
|
|
|
static void updateARMVFPArgs(Ctx &ctx, const ARMAttributeParser &attributes,
|
2022-08-03 21:49:17 -07:00
|
|
|
const InputFile *f) {
|
2022-12-02 08:02:19 +00:00
|
|
|
std::optional<unsigned> attr =
|
2022-08-03 21:49:17 -07:00
|
|
|
attributes.getAttributeValue(ARMBuildAttrs::ABI_VFP_args);
|
|
|
|
if (!attr)
|
|
|
|
// If an ABI tag isn't present then it is implicitly given the value of 0
|
|
|
|
// which maps to ARMBuildAttrs::BaseAAPCS. However many assembler files,
|
|
|
|
// including some in glibc that don't use FP args (and should have value 3)
|
|
|
|
// don't have the attribute so we do not consider an implicit value of 0
|
|
|
|
// as a clash.
|
|
|
|
return;
|
|
|
|
|
|
|
|
unsigned vfpArgs = *attr;
|
|
|
|
ARMVFPArgKind arg;
|
|
|
|
switch (vfpArgs) {
|
|
|
|
case ARMBuildAttrs::BaseAAPCS:
|
|
|
|
arg = ARMVFPArgKind::Base;
|
|
|
|
break;
|
|
|
|
case ARMBuildAttrs::HardFPAAPCS:
|
|
|
|
arg = ARMVFPArgKind::VFP;
|
|
|
|
break;
|
|
|
|
case ARMBuildAttrs::ToolChainFPPCS:
|
|
|
|
// Tool chain specific convention that conforms to neither AAPCS variant.
|
|
|
|
arg = ARMVFPArgKind::ToolChain;
|
|
|
|
break;
|
|
|
|
case ARMBuildAttrs::CompatibleFPAAPCS:
|
|
|
|
// Object compatible with all conventions.
|
|
|
|
return;
|
|
|
|
default:
|
2024-11-24 12:13:01 -08:00
|
|
|
ErrAlways(ctx) << f << ": unknown Tag_ABI_VFP_args value: " << vfpArgs;
|
2022-08-03 21:49:17 -07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
// Follow ld.bfd and error if there is a mix of calling conventions.
|
2024-09-21 12:47:47 -07:00
|
|
|
if (ctx.arg.armVFPArgs != arg && ctx.arg.armVFPArgs != ARMVFPArgKind::Default)
|
2024-11-06 22:04:52 -08:00
|
|
|
ErrAlways(ctx) << f << ": incompatible Tag_ABI_VFP_args";
|
2022-08-03 21:49:17 -07:00
|
|
|
else
|
2024-09-21 12:47:47 -07:00
|
|
|
ctx.arg.armVFPArgs = arg;
|
2022-08-03 21:49:17 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// The ARM support in lld makes some use of instructions that are not available
|
|
|
|
// on all ARM architectures. Namely:
|
|
|
|
// - Use of BLX instruction for interworking between ARM and Thumb state.
|
|
|
|
// - Use of the extended Thumb branch encoding in relocation.
|
|
|
|
// - Use of the MOVT/MOVW instructions in Thumb Thunks.
|
|
|
|
// The ARM Attributes section contains information about the architecture chosen
|
|
|
|
// at compile time. We follow the convention that if at least one input object
|
|
|
|
// is compiled with an architecture that supports these features then lld is
|
|
|
|
// permitted to use them.
|
2024-10-03 23:06:18 -07:00
|
|
|
static void updateSupportedARMFeatures(Ctx &ctx,
|
|
|
|
const ARMAttributeParser &attributes) {
|
2022-12-02 08:02:19 +00:00
|
|
|
std::optional<unsigned> attr =
|
2022-08-03 21:49:17 -07:00
|
|
|
attributes.getAttributeValue(ARMBuildAttrs::CPU_arch);
|
|
|
|
if (!attr)
|
|
|
|
return;
|
2022-12-17 03:19:47 +00:00
|
|
|
auto arch = *attr;
|
2022-08-03 21:49:17 -07:00
|
|
|
switch (arch) {
|
|
|
|
case ARMBuildAttrs::Pre_v4:
|
|
|
|
case ARMBuildAttrs::v4:
|
|
|
|
case ARMBuildAttrs::v4T:
|
|
|
|
// Architectures prior to v5 do not support BLX instruction
|
|
|
|
break;
|
|
|
|
case ARMBuildAttrs::v5T:
|
|
|
|
case ARMBuildAttrs::v5TE:
|
|
|
|
case ARMBuildAttrs::v5TEJ:
|
|
|
|
case ARMBuildAttrs::v6:
|
|
|
|
case ARMBuildAttrs::v6KZ:
|
|
|
|
case ARMBuildAttrs::v6K:
|
2024-09-21 12:47:47 -07:00
|
|
|
ctx.arg.armHasBlx = true;
|
2022-08-03 21:49:17 -07:00
|
|
|
// Architectures used in pre-Cortex processors do not support
|
|
|
|
// The J1 = 1 J2 = 1 Thumb branch range extension, with the exception
|
|
|
|
// of Architecture v6T2 (arm1156t2-s and arm1156t2f-s) that do.
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
// All other Architectures have BLX and extended branch encoding
|
2024-09-21 12:47:47 -07:00
|
|
|
ctx.arg.armHasBlx = true;
|
|
|
|
ctx.arg.armJ1J2BranchEncoding = true;
|
2022-08-03 21:49:17 -07:00
|
|
|
if (arch != ARMBuildAttrs::v6_M && arch != ARMBuildAttrs::v6S_M)
|
|
|
|
// All Architectures used in Cortex processors with the exception
|
|
|
|
// of v6-M and v6S-M have the MOVT and MOVW instructions.
|
2024-09-21 12:47:47 -07:00
|
|
|
ctx.arg.armHasMovtMovw = true;
|
2022-08-03 21:49:17 -07:00
|
|
|
break;
|
|
|
|
}
|
[LLD][ELF] Cortex-M Security Extensions (CMSE) Support
This commit provides linker support for Cortex-M Security Extensions (CMSE).
The specification for this feature can be found in ARM v8-M Security Extensions:
Requirements on Development Tools.
The linker synthesizes a security gateway veneer in a special section;
`.gnu.sgstubs`, when it finds non-local symbols `__acle_se_<entry>` and `<entry>`,
defined relative to the same text section and having the same address. The
address of `<entry>` is retargeted to the starting address of the
linker-synthesized security gateway veneer in section `.gnu.sgstubs`.
In summary, the linker translates input:
```
.text
entry:
__acle_se_entry:
[entry_code]
```
into:
```
.section .gnu.sgstubs
entry:
SG
B.W __acle_se_entry
.text
__acle_se_entry:
[entry_code]
```
If addresses of `__acle_se_<entry>` and `<entry>` are not equal, the linker
considers that `<entry>` already defines a secure gateway veneer so does not
synthesize one.
If `--out-implib=<out.lib>` is specified, the linker writes the list of secure
gateway veneers into a CMSE import library `<out.lib>`. The CMSE import library
will have 3 sections: `.symtab`, `.strtab`, `.shstrtab`. For every secure gateway
veneer <entry> at address `<addr>`, `.symtab` contains a `SHN_ABS` symbol `<entry>` with
value `<addr>`.
If `--in-implib=<in.lib>` is specified, the linker reads the existing CMSE import
library `<in.lib>` and preserves the entry function addresses in the resulting
executable and new import library.
Reviewed By: MaskRay, peter.smith
Differential Revision: https://reviews.llvm.org/D139092
2023-07-06 10:45:10 +01:00
|
|
|
|
|
|
|
// Only ARMv8-M or later architectures have CMSE support.
|
|
|
|
std::optional<unsigned> profile =
|
|
|
|
attributes.getAttributeValue(ARMBuildAttrs::CPU_arch_profile);
|
|
|
|
if (!profile)
|
|
|
|
return;
|
|
|
|
if (arch >= ARMBuildAttrs::CPUArch::v8_M_Base &&
|
|
|
|
profile == ARMBuildAttrs::MicroControllerProfile)
|
2024-09-21 12:47:47 -07:00
|
|
|
ctx.arg.armCMSESupport = true;
|
2024-05-29 13:28:32 -07:00
|
|
|
|
|
|
|
// The thumb PLT entries require Thumb2 which can be used on multiple archs.
|
|
|
|
// For now, let's limit it to ones where ARM isn't available and we know have
|
|
|
|
// Thumb2.
|
|
|
|
std::optional<unsigned> armISA =
|
|
|
|
attributes.getAttributeValue(ARMBuildAttrs::ARM_ISA_use);
|
|
|
|
std::optional<unsigned> thumb =
|
|
|
|
attributes.getAttributeValue(ARMBuildAttrs::THUMB_ISA_use);
|
2024-09-21 12:47:47 -07:00
|
|
|
ctx.arg.armHasArmISA |= armISA && *armISA >= ARMBuildAttrs::Allowed;
|
|
|
|
ctx.arg.armHasThumb2ISA |= thumb && *thumb >= ARMBuildAttrs::AllowThumb32;
|
2022-08-03 21:49:17 -07:00
|
|
|
}
|
|
|
|
|
2024-10-06 18:09:52 -07:00
|
|
|
InputFile::InputFile(Ctx &ctx, Kind k, MemoryBufferRef m)
|
|
|
|
: ctx(ctx), mb(m), groupId(ctx.driver.nextGroupId), fileKind(k) {
|
Add --warn-backrefs to maintain compatibility with other linkers
I'm proposing a new command line flag, --warn-backrefs in this patch.
The flag and the feature proposed below don't exist in GNU linkers
nor the current lld.
--warn-backrefs is an option to detect reverse or cyclic dependencies
between static archives, and it can be used to keep your program
compatible with GNU linkers after you switch to lld. I'll explain the
feature and why you may find it useful below.
lld's symbol resolution semantics is more relaxed than traditional
Unix linkers. Therefore,
ld.lld foo.a bar.o
succeeds even if bar.o contains an undefined symbol that have to be
resolved by some object file in foo.a. Traditional Unix linkers
don't allow this kind of backward reference, as they visit each
file only once from left to right in the command line while
resolving all undefined symbol at the moment of visiting.
In the above case, since there's no undefined symbol when a linker
visits foo.a, no files are pulled out from foo.a, and because the
linker forgets about foo.a after visiting, it can't resolve
undefined symbols that could have been resolved otherwise.
That lld accepts more relaxed form means (besides it makes more
sense) that you can accidentally write a command line or a build
file that works only with lld, even if you have a plan to
distribute it to wider users who may be using GNU linkers. With
--check-library-dependency, you can detect a library order that
doesn't work with other Unix linkers.
The option is also useful to detect cyclic dependencies between
static archives. Again, lld accepts
ld.lld foo.a bar.a
even if foo.a and bar.a depend on each other. With --warn-backrefs
it is handled as an error.
Here is how the option works. We assign a group ID to each file. A
file with a smaller group ID can pull out object files from an
archive file with an equal or greater group ID. Otherwise, it is a
reverse dependency and an error.
A file outside --{start,end}-group gets a fresh ID when
instantiated. All files within the same --{start,end}-group get the
same group ID. E.g.
ld.lld A B --start-group C D --end-group E
A and B form group 0, C, D and their member object files form group
1, and E forms group 2. I think that you can see how this group
assignment rule simulates the traditional linker's semantics.
Differential Revision: https://reviews.llvm.org/D45195
llvm-svn: 329636
2018-04-09 23:05:48 +00:00
|
|
|
// All files within the same --{start,end}-group get the same group ID.
|
|
|
|
// Otherwise, a new file will get a new group ID.
|
2024-10-06 17:38:35 -07:00
|
|
|
if (!ctx.driver.isInGroup)
|
|
|
|
++ctx.driver.nextGroupId;
|
Add --warn-backrefs to maintain compatibility with other linkers
I'm proposing a new command line flag, --warn-backrefs in this patch.
The flag and the feature proposed below don't exist in GNU linkers
nor the current lld.
--warn-backrefs is an option to detect reverse or cyclic dependencies
between static archives, and it can be used to keep your program
compatible with GNU linkers after you switch to lld. I'll explain the
feature and why you may find it useful below.
lld's symbol resolution semantics is more relaxed than traditional
Unix linkers. Therefore,
ld.lld foo.a bar.o
succeeds even if bar.o contains an undefined symbol that have to be
resolved by some object file in foo.a. Traditional Unix linkers
don't allow this kind of backward reference, as they visit each
file only once from left to right in the command line while
resolving all undefined symbol at the moment of visiting.
In the above case, since there's no undefined symbol when a linker
visits foo.a, no files are pulled out from foo.a, and because the
linker forgets about foo.a after visiting, it can't resolve
undefined symbols that could have been resolved otherwise.
That lld accepts more relaxed form means (besides it makes more
sense) that you can accidentally write a command line or a build
file that works only with lld, even if you have a plan to
distribute it to wider users who may be using GNU linkers. With
--check-library-dependency, you can detect a library order that
doesn't work with other Unix linkers.
The option is also useful to detect cyclic dependencies between
static archives. Again, lld accepts
ld.lld foo.a bar.a
even if foo.a and bar.a depend on each other. With --warn-backrefs
it is handled as an error.
Here is how the option works. We assign a group ID to each file. A
file with a smaller group ID can pull out object files from an
archive file with an equal or greater group ID. Otherwise, it is a
reverse dependency and an error.
A file outside --{start,end}-group gets a fresh ID when
instantiated. All files within the same --{start,end}-group get the
same group ID. E.g.
ld.lld A B --start-group C D --end-group E
A and B form group 0, C, D and their member object files form group
1, and E forms group 2. I think that you can see how this group
assignment rule simulates the traditional linker's semantics.
Differential Revision: https://reviews.llvm.org/D45195
llvm-svn: 329636
2018-04-09 23:05:48 +00:00
|
|
|
}
|
2017-03-30 21:13:00 +00:00
|
|
|
|
2024-11-16 23:50:34 -08:00
|
|
|
InputFile::~InputFile() {}
|
|
|
|
|
2024-10-06 11:27:24 -07:00
|
|
|
std::optional<MemoryBufferRef> elf::readFile(Ctx &ctx, StringRef path) {
|
2020-11-03 14:41:09 +00:00
|
|
|
llvm::TimeTraceScope timeScope("Load input files", path);
|
|
|
|
|
2017-07-20 18:17:55 +00:00
|
|
|
// The --chroot option changes our virtual root directory.
|
|
|
|
// This is useful when you are dealing with files created by --reproduce.
|
2024-09-21 12:47:47 -07:00
|
|
|
if (!ctx.arg.chroot.empty() && path.starts_with("/"))
|
2024-11-16 22:34:12 -08:00
|
|
|
path = ctx.saver.save(ctx.arg.chroot + path);
|
2017-07-20 18:17:55 +00:00
|
|
|
|
2023-04-26 13:18:55 -07:00
|
|
|
bool remapped = false;
|
2024-09-21 12:47:47 -07:00
|
|
|
auto it = ctx.arg.remapInputs.find(path);
|
|
|
|
if (it != ctx.arg.remapInputs.end()) {
|
2023-04-26 13:18:55 -07:00
|
|
|
path = it->second;
|
|
|
|
remapped = true;
|
|
|
|
} else {
|
2024-09-21 12:47:47 -07:00
|
|
|
for (const auto &[pat, toFile] : ctx.arg.remapInputsWildcards) {
|
2023-04-26 13:18:55 -07:00
|
|
|
if (pat.match(path)) {
|
|
|
|
path = toFile;
|
|
|
|
remapped = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (remapped) {
|
|
|
|
// Use /dev/null to indicate an input file that should be ignored. Change
|
|
|
|
// the path to NUL on Windows.
|
|
|
|
#ifdef _WIN32
|
|
|
|
if (path == "/dev/null")
|
|
|
|
path = "NUL";
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2024-11-07 09:30:20 -08:00
|
|
|
Log(ctx) << path;
|
2024-09-21 12:47:47 -07:00
|
|
|
ctx.arg.dependencyFiles.insert(llvm::CachedHashString(path));
|
2017-07-20 18:17:55 +00:00
|
|
|
|
[NFC] Reordering parameters in getFile and getFileOrSTDIN
In future patches I will be setting the IsText parameter frequently so I will refactor the args to be in the following order. I have removed the FileSize parameter because it is never used.
```
static ErrorOr<std::unique_ptr<MemoryBuffer>>
getFile(const Twine &Filename, bool IsText = false,
bool RequiresNullTerminator = true, bool IsVolatile = false);
static ErrorOr<std::unique_ptr<MemoryBuffer>>
getFileOrSTDIN(const Twine &Filename, bool IsText = false,
bool RequiresNullTerminator = true);
static ErrorOr<std::unique_ptr<MB>>
getFileAux(const Twine &Filename, uint64_t MapSize, uint64_t Offset,
bool IsText, bool RequiresNullTerminator, bool IsVolatile);
static ErrorOr<std::unique_ptr<WritableMemoryBuffer>>
getFile(const Twine &Filename, bool IsVolatile = false);
```
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D99182
2021-03-25 09:47:25 -04:00
|
|
|
auto mbOrErr = MemoryBuffer::getFile(path, /*IsText=*/false,
|
|
|
|
/*RequiresNullTerminator=*/false);
|
2017-01-09 01:42:02 +00:00
|
|
|
if (auto ec = mbOrErr.getError()) {
|
2024-11-06 22:04:52 -08:00
|
|
|
ErrAlways(ctx) << "cannot open " << path << ": " << ec.message();
|
2022-11-26 19:19:15 -08:00
|
|
|
return std::nullopt;
|
2017-01-09 01:42:02 +00:00
|
|
|
}
|
2017-02-21 23:22:56 +00:00
|
|
|
|
2021-12-30 11:36:57 -08:00
|
|
|
MemoryBufferRef mbref = (*mbOrErr)->getMemBufferRef();
|
2022-10-01 12:06:33 -07:00
|
|
|
ctx.memoryBuffers.push_back(std::move(*mbOrErr)); // take MB ownership
|
2017-01-09 01:42:02 +00:00
|
|
|
|
2024-07-28 15:32:22 -07:00
|
|
|
if (ctx.tar)
|
|
|
|
ctx.tar->append(relativeToRoot(path), mbref.getBuffer());
|
2017-01-09 01:42:02 +00:00
|
|
|
return mbref;
|
|
|
|
}
|
|
|
|
|
2019-05-14 12:03:13 +00:00
|
|
|
// All input object files must be for the same architecture
|
|
|
|
// (e.g. it does not make sense to link x86 object files with
|
|
|
|
// MIPS object files.) This function checks for that error.
|
2024-10-03 23:06:18 -07:00
|
|
|
static bool isCompatible(Ctx &ctx, InputFile *file) {
|
2019-05-14 12:03:13 +00:00
|
|
|
if (!file->isElf() && !isa<BitcodeFile>(file))
|
|
|
|
return true;
|
|
|
|
|
2024-09-21 12:47:47 -07:00
|
|
|
if (file->ekind == ctx.arg.ekind && file->emachine == ctx.arg.emachine) {
|
|
|
|
if (ctx.arg.emachine != EM_MIPS)
|
2019-05-14 12:03:13 +00:00
|
|
|
return true;
|
2024-10-06 00:14:12 -07:00
|
|
|
if (isMipsN32Abi(ctx, *file) == ctx.arg.mipsN32Abi)
|
2019-05-14 12:03:13 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
[ELF] Correct error message when OUTPUT_FORMAT is used
Any OUTPUT_FORMAT in a linker script overrides the emulation passed on
the command line, so record the passed bfdname and use that in the error
message about incompatible input files.
This prevents confusing error messages. For example, if you explicitly
pass `-m elf_x86_64` to LLD but accidentally include a linker script
which sets `OUTPUT_FORMAT(elf32-i386)`, LLD would previously complain
about your input files being compatible with elf_x86_64, which isn't the
actual issue, and is confusing because the input files are in fact
x86-64 ELF files.
Interestingly enough, this also prevents a segfault! When we don't pass
`-m` and we have an object file which is incompatible with the
`OUTPUT_FORMAT` set by a linker script, the object file is checked for
compatibility before it's added to the objectFiles vector.
config->emulation, objectFiles, and sharedFiles will all be empty, so
we'll attempt to access bitcodeFiles[0], but bitcodeFiles is also empty,
so we'll segfault. This commit prevents the segfault by adding
OUTPUT_FORMAT as a possible source of machine configuration, and it also
adds an llvm_unreachable to diagnose similar issues in the future.
Differential Revision: https://reviews.llvm.org/D76109
2020-03-12 15:25:36 -07:00
|
|
|
StringRef target =
|
2024-09-21 12:47:47 -07:00
|
|
|
!ctx.arg.bfdname.empty() ? ctx.arg.bfdname : ctx.arg.emulation;
|
[ELF] Correct error message when OUTPUT_FORMAT is used
Any OUTPUT_FORMAT in a linker script overrides the emulation passed on
the command line, so record the passed bfdname and use that in the error
message about incompatible input files.
This prevents confusing error messages. For example, if you explicitly
pass `-m elf_x86_64` to LLD but accidentally include a linker script
which sets `OUTPUT_FORMAT(elf32-i386)`, LLD would previously complain
about your input files being compatible with elf_x86_64, which isn't the
actual issue, and is confusing because the input files are in fact
x86-64 ELF files.
Interestingly enough, this also prevents a segfault! When we don't pass
`-m` and we have an object file which is incompatible with the
`OUTPUT_FORMAT` set by a linker script, the object file is checked for
compatibility before it's added to the objectFiles vector.
config->emulation, objectFiles, and sharedFiles will all be empty, so
we'll attempt to access bitcodeFiles[0], but bitcodeFiles is also empty,
so we'll segfault. This commit prevents the segfault by adding
OUTPUT_FORMAT as a possible source of machine configuration, and it also
adds an llvm_unreachable to diagnose similar issues in the future.
Differential Revision: https://reviews.llvm.org/D76109
2020-03-12 15:25:36 -07:00
|
|
|
if (!target.empty()) {
|
2024-11-24 11:30:21 -08:00
|
|
|
Err(ctx) << file << " is incompatible with " << target;
|
2019-07-29 05:24:51 +00:00
|
|
|
return false;
|
2019-05-14 12:03:13 +00:00
|
|
|
}
|
|
|
|
|
2022-02-05 23:34:14 -08:00
|
|
|
InputFile *existing = nullptr;
|
2022-10-01 12:06:33 -07:00
|
|
|
if (!ctx.objectFiles.empty())
|
|
|
|
existing = ctx.objectFiles[0];
|
|
|
|
else if (!ctx.sharedFiles.empty())
|
|
|
|
existing = ctx.sharedFiles[0];
|
|
|
|
else if (!ctx.bitcodeFiles.empty())
|
|
|
|
existing = ctx.bitcodeFiles[0];
|
2024-11-24 11:30:21 -08:00
|
|
|
auto diag = Err(ctx);
|
|
|
|
diag << file << " is incompatible";
|
2022-02-05 23:34:14 -08:00
|
|
|
if (existing)
|
2024-11-24 11:30:21 -08:00
|
|
|
diag << " with " << existing;
|
2019-05-14 12:03:13 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2024-09-29 16:06:47 -07:00
|
|
|
template <class ELFT> static void doParseFile(Ctx &ctx, InputFile *file) {
|
2024-10-03 23:06:18 -07:00
|
|
|
if (!isCompatible(ctx, file))
|
2019-05-14 12:03:13 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
// Lazy object file
|
2021-12-22 17:41:50 -08:00
|
|
|
if (file->lazy) {
|
|
|
|
if (auto *f = dyn_cast<BitcodeFile>(file)) {
|
2022-10-01 12:06:33 -07:00
|
|
|
ctx.lazyBitcodeFiles.push_back(f);
|
2021-12-22 17:41:50 -08:00
|
|
|
f->parseLazy();
|
|
|
|
} else {
|
|
|
|
cast<ObjFile<ELFT>>(file)->parseLazy();
|
|
|
|
}
|
2019-05-14 12:03:13 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2024-09-21 12:47:47 -07:00
|
|
|
if (ctx.arg.trace)
|
2024-11-16 15:34:42 -08:00
|
|
|
Msg(ctx) << file;
|
2019-05-14 12:03:13 +00:00
|
|
|
|
2023-09-16 00:41:23 -07:00
|
|
|
if (file->kind() == InputFile::ObjKind) {
|
|
|
|
ctx.objectFiles.push_back(cast<ELFFileBase>(file));
|
|
|
|
cast<ObjFile<ELFT>>(file)->parse();
|
|
|
|
} else if (auto *f = dyn_cast<SharedFile>(file)) {
|
2019-05-14 12:03:13 +00:00
|
|
|
f->parse<ELFT>();
|
2023-09-16 00:41:23 -07:00
|
|
|
} else if (auto *f = dyn_cast<BitcodeFile>(file)) {
|
2022-10-01 12:06:33 -07:00
|
|
|
ctx.bitcodeFiles.push_back(f);
|
2022-08-09 21:46:28 -07:00
|
|
|
f->parse();
|
2023-09-16 00:41:23 -07:00
|
|
|
} else {
|
|
|
|
ctx.binaryFiles.push_back(cast<BinaryFile>(file));
|
|
|
|
cast<BinaryFile>(file)->parse();
|
2019-05-14 12:03:13 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-16 03:45:13 +00:00
|
|
|
// Add symbols in File to the symbol table.
|
2024-09-29 16:06:47 -07:00
|
|
|
void elf::parseFile(Ctx &ctx, InputFile *file) {
|
|
|
|
invokeELFT(doParseFile, ctx, file);
|
|
|
|
}
|
2019-05-16 03:45:13 +00:00
|
|
|
|
2024-02-13 18:31:32 -05:00
|
|
|
// This function is explicitly instantiated in ARM.cpp. Mark it extern here,
|
2023-10-03 10:12:09 -04:00
|
|
|
// to avoid warnings when building with MSVC.
|
|
|
|
extern template void ObjFile<ELF32LE>::importCmseSymbols();
|
|
|
|
extern template void ObjFile<ELF32BE>::importCmseSymbols();
|
|
|
|
extern template void ObjFile<ELF64LE>::importCmseSymbols();
|
|
|
|
extern template void ObjFile<ELF64BE>::importCmseSymbols();
|
|
|
|
|
2024-03-25 16:02:34 -07:00
|
|
|
template <class ELFT>
|
2024-11-16 23:50:34 -08:00
|
|
|
static void
|
|
|
|
doParseFiles(Ctx &ctx,
|
|
|
|
const SmallVector<std::unique_ptr<InputFile>, 0> &files) {
|
2024-03-25 16:02:34 -07:00
|
|
|
// Add all files to the symbol table. This will add almost all symbols that we
|
|
|
|
// need to the symbol table. This process might add files to the link due to
|
|
|
|
// addDependentLibrary.
|
|
|
|
for (size_t i = 0; i < files.size(); ++i) {
|
|
|
|
llvm::TimeTraceScope timeScope("Parse input files", files[i]->getName());
|
2024-11-16 23:50:34 -08:00
|
|
|
doParseFile<ELFT>(ctx, files[i].get());
|
2024-03-25 16:02:34 -07:00
|
|
|
}
|
2024-09-29 16:06:47 -07:00
|
|
|
if (ctx.driver.armCmseImpLib)
|
|
|
|
cast<ObjFile<ELFT>>(*ctx.driver.armCmseImpLib).importCmseSymbols();
|
[LLD][ELF] Cortex-M Security Extensions (CMSE) Support
This commit provides linker support for Cortex-M Security Extensions (CMSE).
The specification for this feature can be found in ARM v8-M Security Extensions:
Requirements on Development Tools.
The linker synthesizes a security gateway veneer in a special section;
`.gnu.sgstubs`, when it finds non-local symbols `__acle_se_<entry>` and `<entry>`,
defined relative to the same text section and having the same address. The
address of `<entry>` is retargeted to the starting address of the
linker-synthesized security gateway veneer in section `.gnu.sgstubs`.
In summary, the linker translates input:
```
.text
entry:
__acle_se_entry:
[entry_code]
```
into:
```
.section .gnu.sgstubs
entry:
SG
B.W __acle_se_entry
.text
__acle_se_entry:
[entry_code]
```
If addresses of `__acle_se_<entry>` and `<entry>` are not equal, the linker
considers that `<entry>` already defines a secure gateway veneer so does not
synthesize one.
If `--out-implib=<out.lib>` is specified, the linker writes the list of secure
gateway veneers into a CMSE import library `<out.lib>`. The CMSE import library
will have 3 sections: `.symtab`, `.strtab`, `.shstrtab`. For every secure gateway
veneer <entry> at address `<addr>`, `.symtab` contains a `SHN_ABS` symbol `<entry>` with
value `<addr>`.
If `--in-implib=<in.lib>` is specified, the linker reads the existing CMSE import
library `<in.lib>` and preserves the entry function addresses in the resulting
executable and new import library.
Reviewed By: MaskRay, peter.smith
Differential Revision: https://reviews.llvm.org/D139092
2023-07-06 10:45:10 +01:00
|
|
|
}
|
|
|
|
|
2024-11-16 23:50:34 -08:00
|
|
|
void elf::parseFiles(Ctx &ctx,
|
|
|
|
const SmallVector<std::unique_ptr<InputFile>, 0> &files) {
|
2024-03-25 16:02:34 -07:00
|
|
|
llvm::TimeTraceScope timeScope("Parse input files");
|
2024-09-29 16:06:47 -07:00
|
|
|
invokeELFT(doParseFiles, ctx, files);
|
[LLD][ELF] Cortex-M Security Extensions (CMSE) Support
This commit provides linker support for Cortex-M Security Extensions (CMSE).
The specification for this feature can be found in ARM v8-M Security Extensions:
Requirements on Development Tools.
The linker synthesizes a security gateway veneer in a special section;
`.gnu.sgstubs`, when it finds non-local symbols `__acle_se_<entry>` and `<entry>`,
defined relative to the same text section and having the same address. The
address of `<entry>` is retargeted to the starting address of the
linker-synthesized security gateway veneer in section `.gnu.sgstubs`.
In summary, the linker translates input:
```
.text
entry:
__acle_se_entry:
[entry_code]
```
into:
```
.section .gnu.sgstubs
entry:
SG
B.W __acle_se_entry
.text
__acle_se_entry:
[entry_code]
```
If addresses of `__acle_se_<entry>` and `<entry>` are not equal, the linker
considers that `<entry>` already defines a secure gateway veneer so does not
synthesize one.
If `--out-implib=<out.lib>` is specified, the linker writes the list of secure
gateway veneers into a CMSE import library `<out.lib>`. The CMSE import library
will have 3 sections: `.symtab`, `.strtab`, `.shstrtab`. For every secure gateway
veneer <entry> at address `<addr>`, `.symtab` contains a `SHN_ABS` symbol `<entry>` with
value `<addr>`.
If `--in-implib=<in.lib>` is specified, the linker reads the existing CMSE import
library `<in.lib>` and preserves the entry function addresses in the resulting
executable and new import library.
Reviewed By: MaskRay, peter.smith
Differential Revision: https://reviews.llvm.org/D139092
2023-07-06 10:45:10 +01:00
|
|
|
}
|
|
|
|
|
2017-12-23 17:21:39 +00:00
|
|
|
// Concatenates arguments to construct a string representing an error location.
|
2020-09-09 10:48:21 +01:00
|
|
|
StringRef InputFile::getNameForScript() const {
|
|
|
|
if (archiveName.empty())
|
|
|
|
return getName();
|
|
|
|
|
|
|
|
if (nameForScriptCache.empty())
|
|
|
|
nameForScriptCache = (archiveName + Twine(':') + getName()).str();
|
|
|
|
|
|
|
|
return nameForScriptCache;
|
|
|
|
}
|
|
|
|
|
2022-07-29 17:07:09 -07:00
|
|
|
// An ELF object file may contain a `.deplibs` section. If it exists, the
|
|
|
|
// section contains a list of library specifiers such as `m` for libm. This
|
|
|
|
// function resolves a given name by finding the first matching library checking
|
|
|
|
// the various ways that a library can be specified to LLD. This ELF extension
|
|
|
|
// is a form of autolinking and is called `dependent libraries`. It is currently
|
|
|
|
// unique to LLVM and lld.
|
2024-10-03 23:06:18 -07:00
|
|
|
static void addDependentLibrary(Ctx &ctx, StringRef specifier,
|
|
|
|
const InputFile *f) {
|
2024-09-21 12:47:47 -07:00
|
|
|
if (!ctx.arg.dependentLibraries)
|
2022-07-29 17:07:09 -07:00
|
|
|
return;
|
2024-10-06 11:27:24 -07:00
|
|
|
if (std::optional<std::string> s = searchLibraryBaseName(ctx, specifier))
|
2024-11-16 22:34:12 -08:00
|
|
|
ctx.driver.addFile(ctx.saver.save(*s), /*withLOption=*/true);
|
2024-10-06 11:27:24 -07:00
|
|
|
else if (std::optional<std::string> s = findFromSearchPaths(ctx, specifier))
|
2024-11-16 22:34:12 -08:00
|
|
|
ctx.driver.addFile(ctx.saver.save(*s), /*withLOption=*/true);
|
2022-07-29 17:07:09 -07:00
|
|
|
else if (fs::exists(specifier))
|
2022-10-01 15:12:50 -07:00
|
|
|
ctx.driver.addFile(specifier, /*withLOption=*/false);
|
2022-07-29 17:07:09 -07:00
|
|
|
else
|
2024-11-06 22:04:52 -08:00
|
|
|
ErrAlways(ctx)
|
|
|
|
<< f << ": unable to find library from dependent library specifier: "
|
|
|
|
<< specifier;
|
2022-07-29 17:07:09 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
// Record the membership of a section group so that in the garbage collection
|
|
|
|
// pass, section group members are kept or discarded as a unit.
|
|
|
|
template <class ELFT>
|
|
|
|
static void handleSectionGroup(ArrayRef<InputSectionBase *> sections,
|
|
|
|
ArrayRef<typename ELFT::Word> entries) {
|
|
|
|
bool hasAlloc = false;
|
|
|
|
for (uint32_t index : entries.slice(1)) {
|
|
|
|
if (index >= sections.size())
|
|
|
|
return;
|
|
|
|
if (InputSectionBase *s = sections[index])
|
|
|
|
if (s != &InputSection::discarded && s->flags & SHF_ALLOC)
|
|
|
|
hasAlloc = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If any member has the SHF_ALLOC flag, the whole group is subject to garbage
|
|
|
|
// collection. See the comment in markLive(). This rule retains .debug_types
|
|
|
|
// and .rela.debug_types.
|
|
|
|
if (!hasAlloc)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Connect the members in a circular doubly-linked list via
|
|
|
|
// nextInSectionGroup.
|
|
|
|
InputSectionBase *head;
|
|
|
|
InputSectionBase *prev = nullptr;
|
|
|
|
for (uint32_t index : entries.slice(1)) {
|
|
|
|
InputSectionBase *s = sections[index];
|
|
|
|
if (!s || s == &InputSection::discarded)
|
|
|
|
continue;
|
|
|
|
if (prev)
|
|
|
|
prev->nextInSectionGroup = s;
|
|
|
|
else
|
|
|
|
head = s;
|
|
|
|
prev = s;
|
|
|
|
}
|
|
|
|
if (prev)
|
|
|
|
prev->nextInSectionGroup = head;
|
|
|
|
}
|
|
|
|
|
2024-11-29 15:48:46 -08:00
|
|
|
template <class ELFT> void ObjFile<ELFT>::initDwarf() {
|
|
|
|
dwarf = std::make_unique<DWARFCache>(std::make_unique<DWARFContext>(
|
|
|
|
std::make_unique<LLDDwarfObj<ELFT>>(this), "",
|
|
|
|
[&](Error err) { Warn(ctx) << getName() + ": " << std::move(err); },
|
|
|
|
[&](Error warning) {
|
|
|
|
Warn(ctx) << getName() << ": " << std::move(warning);
|
|
|
|
}));
|
2016-10-26 11:07:09 +00:00
|
|
|
}
|
|
|
|
|
2024-11-29 15:48:46 -08:00
|
|
|
DWARFCache *ELFFileBase::getDwarf() {
|
|
|
|
assert(fileKind == ObjKind);
|
|
|
|
llvm::call_once(initDwarf, [this]() {
|
|
|
|
switch (ekind) {
|
|
|
|
default:
|
|
|
|
llvm_unreachable("");
|
|
|
|
case ELF32LEKind:
|
|
|
|
return cast<ObjFile<ELF32LE>>(this)->initDwarf();
|
|
|
|
case ELF32BEKind:
|
|
|
|
return cast<ObjFile<ELF32BE>>(this)->initDwarf();
|
|
|
|
case ELF64LEKind:
|
|
|
|
return cast<ObjFile<ELF64LE>>(this)->initDwarf();
|
|
|
|
case ELF64BEKind:
|
|
|
|
return cast<ObjFile<ELF64BE>>(this)->initDwarf();
|
2019-02-27 13:17:36 +00:00
|
|
|
}
|
2024-11-29 15:48:46 -08:00
|
|
|
});
|
|
|
|
return dwarf.get();
|
2017-03-30 19:13:47 +00:00
|
|
|
}
|
|
|
|
|
2024-10-06 18:09:52 -07:00
|
|
|
ELFFileBase::ELFFileBase(Ctx &ctx, Kind k, ELFKind ekind, MemoryBufferRef mb)
|
|
|
|
: InputFile(ctx, k, mb) {
|
2022-10-02 20:16:13 -07:00
|
|
|
this->ekind = ekind;
|
2022-10-02 21:10:28 -07:00
|
|
|
}
|
|
|
|
|
2024-11-29 15:48:46 -08:00
|
|
|
ELFFileBase::~ELFFileBase() {}
|
|
|
|
|
2022-10-02 21:10:28 -07:00
|
|
|
template <typename Elf_Shdr>
|
|
|
|
static const Elf_Shdr *findSection(ArrayRef<Elf_Shdr> sections, uint32_t type) {
|
|
|
|
for (const Elf_Shdr &sec : sections)
|
|
|
|
if (sec.sh_type == type)
|
|
|
|
return &sec;
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ELFFileBase::init() {
|
2019-05-28 05:17:21 +00:00
|
|
|
switch (ekind) {
|
|
|
|
case ELF32LEKind:
|
2022-10-02 21:10:28 -07:00
|
|
|
init<ELF32LE>(fileKind);
|
2019-05-28 05:17:21 +00:00
|
|
|
break;
|
|
|
|
case ELF32BEKind:
|
2022-10-02 21:10:28 -07:00
|
|
|
init<ELF32BE>(fileKind);
|
2019-05-28 05:17:21 +00:00
|
|
|
break;
|
|
|
|
case ELF64LEKind:
|
2022-10-02 21:10:28 -07:00
|
|
|
init<ELF64LE>(fileKind);
|
2019-05-28 05:17:21 +00:00
|
|
|
break;
|
|
|
|
case ELF64BEKind:
|
2022-10-02 21:10:28 -07:00
|
|
|
init<ELF64BE>(fileKind);
|
2019-05-28 05:17:21 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
llvm_unreachable("getELFKind");
|
|
|
|
}
|
|
|
|
}
|
2017-04-26 22:51:51 +00:00
|
|
|
|
2022-09-04 14:44:58 -07:00
|
|
|
template <class ELFT> void ELFFileBase::init(InputFile::Kind k) {
|
2019-05-28 05:17:21 +00:00
|
|
|
using Elf_Shdr = typename ELFT::Shdr;
|
|
|
|
using Elf_Sym = typename ELFT::Sym;
|
2016-11-03 16:55:44 +00:00
|
|
|
|
2019-05-28 05:17:21 +00:00
|
|
|
// Initialize trivial attributes.
|
|
|
|
const ELFFile<ELFT> &obj = getObj<ELFT>();
|
2020-09-09 17:03:53 +03:00
|
|
|
emachine = obj.getHeader().e_machine;
|
|
|
|
osabi = obj.getHeader().e_ident[llvm::ELF::EI_OSABI];
|
|
|
|
abiVersion = obj.getHeader().e_ident[llvm::ELF::EI_ABIVERSION];
|
2015-10-01 19:52:48 +00:00
|
|
|
|
2024-11-16 11:58:10 -08:00
|
|
|
ArrayRef<Elf_Shdr> sections = CHECK2(obj.sections(), this);
|
2021-12-24 17:10:38 -08:00
|
|
|
elfShdrs = sections.data();
|
|
|
|
numELFShdrs = sections.size();
|
2019-05-28 05:17:21 +00:00
|
|
|
|
|
|
|
// Find a symbol table.
|
|
|
|
const Elf_Shdr *symtabSec =
|
2022-09-04 14:44:58 -07:00
|
|
|
findSection(sections, k == SharedKind ? SHT_DYNSYM : SHT_SYMTAB);
|
2019-05-28 05:17:21 +00:00
|
|
|
|
|
|
|
if (!symtabSec)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Initialize members corresponding to a symbol table.
|
|
|
|
firstGlobal = symtabSec->sh_info;
|
|
|
|
|
2024-11-16 11:58:10 -08:00
|
|
|
ArrayRef<Elf_Sym> eSyms = CHECK2(obj.symbols(symtabSec), this);
|
2019-05-28 05:17:21 +00:00
|
|
|
if (firstGlobal == 0 || firstGlobal > eSyms.size())
|
2024-11-06 21:17:26 -08:00
|
|
|
Fatal(ctx) << this << ": invalid sh_info in symbol table";
|
2019-05-28 05:17:21 +00:00
|
|
|
|
|
|
|
elfSyms = reinterpret_cast<const void *>(eSyms.data());
|
2024-12-08 15:59:03 -08:00
|
|
|
numSymbols = eSyms.size();
|
2024-11-16 11:58:10 -08:00
|
|
|
stringTable = CHECK2(obj.getStringTableForSymtab(*symtabSec, sections), this);
|
2017-04-26 22:51:51 +00:00
|
|
|
}
|
2016-03-11 12:06:30 +00:00
|
|
|
|
2019-04-04 03:13:51 +00:00
|
|
|
template <class ELFT>
|
|
|
|
uint32_t ObjFile<ELFT>::getSectionIndex(const Elf_Sym &sym) const {
|
2024-11-16 11:58:10 -08:00
|
|
|
return CHECK2(
|
2020-09-09 17:03:53 +03:00
|
|
|
this->getObj().getSectionIndex(sym, getELFSyms<ELFT>(), shndxTable),
|
2019-04-05 20:16:26 +00:00
|
|
|
this);
|
2019-04-04 03:13:51 +00:00
|
|
|
}
|
|
|
|
|
2019-06-05 17:39:37 +00:00
|
|
|
template <class ELFT> void ObjFile<ELFT>::parse(bool ignoreComdats) {
|
2022-01-29 16:51:00 -08:00
|
|
|
object::ELFFile<ELFT> obj = this->getObj();
|
2019-07-16 05:50:45 +00:00
|
|
|
// Read a section table. justSymbols is usually false.
|
2022-08-04 11:47:52 -07:00
|
|
|
if (this->justSymbols) {
|
2018-03-30 01:15:36 +00:00
|
|
|
initializeJustSymbols();
|
2022-08-04 11:47:52 -07:00
|
|
|
initializeSymbols(obj);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Handle dependent libraries and selection of section groups as these are not
|
|
|
|
// done in parallel.
|
|
|
|
ArrayRef<Elf_Shdr> objSections = getELFShdrs<ELFT>();
|
2024-11-16 11:58:10 -08:00
|
|
|
StringRef shstrtab = CHECK2(obj.getSectionStringTable(objSections), this);
|
2022-08-04 11:47:52 -07:00
|
|
|
uint64_t size = objSections.size();
|
|
|
|
sections.resize(size);
|
|
|
|
for (size_t i = 0; i != size; ++i) {
|
|
|
|
const Elf_Shdr &sec = objSections[i];
|
2024-12-01 12:03:35 -08:00
|
|
|
if (LLVM_LIKELY(sec.sh_type == SHT_PROGBITS))
|
|
|
|
continue;
|
|
|
|
if (LLVM_LIKELY(sec.sh_type == SHT_GROUP)) {
|
|
|
|
StringRef signature = getShtGroupSignature(objSections, sec);
|
|
|
|
ArrayRef<Elf_Word> entries =
|
|
|
|
CHECK2(obj.template getSectionContentsAsArray<Elf_Word>(sec), this);
|
|
|
|
if (entries.empty())
|
|
|
|
Fatal(ctx) << this << ": empty SHT_GROUP";
|
|
|
|
|
|
|
|
Elf_Word flag = entries[0];
|
|
|
|
if (flag && flag != GRP_COMDAT)
|
|
|
|
Fatal(ctx) << this << ": unsupported SHT_GROUP format";
|
|
|
|
|
|
|
|
bool keepGroup = !flag || ignoreComdats ||
|
|
|
|
ctx.symtab->comdatGroups
|
|
|
|
.try_emplace(CachedHashStringRef(signature), this)
|
|
|
|
.second;
|
|
|
|
if (keepGroup) {
|
|
|
|
if (!ctx.arg.resolveGroups)
|
|
|
|
sections[i] = createInputSection(
|
|
|
|
i, sec, check(obj.getSectionName(sec, shstrtab)));
|
|
|
|
} else {
|
|
|
|
// Otherwise, discard group members.
|
|
|
|
for (uint32_t secIndex : entries.slice(1)) {
|
|
|
|
if (secIndex >= size)
|
|
|
|
Fatal(ctx) << this
|
|
|
|
<< ": invalid section index in group: " << secIndex;
|
|
|
|
sections[secIndex] = &InputSection::discarded;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2024-09-21 12:47:47 -07:00
|
|
|
if (sec.sh_type == SHT_LLVM_DEPENDENT_LIBRARIES && !ctx.arg.relocatable) {
|
2022-08-04 11:47:52 -07:00
|
|
|
StringRef name = check(obj.getSectionName(sec, shstrtab));
|
2024-11-16 11:58:10 -08:00
|
|
|
ArrayRef<char> data = CHECK2(
|
2022-08-04 11:47:52 -07:00
|
|
|
this->getObj().template getSectionContentsAsArray<char>(sec), this);
|
|
|
|
if (!data.empty() && data.back() != '\0') {
|
2024-12-01 12:03:35 -08:00
|
|
|
Err(ctx)
|
2024-11-06 22:04:52 -08:00
|
|
|
<< this
|
|
|
|
<< ": corrupted dependent libraries section (unterminated string): "
|
|
|
|
<< name;
|
2022-08-04 11:47:52 -07:00
|
|
|
} else {
|
|
|
|
for (const char *d = data.begin(), *e = data.end(); d < e;) {
|
|
|
|
StringRef s(d);
|
2024-10-03 23:06:18 -07:00
|
|
|
addDependentLibrary(ctx, s, this);
|
2022-08-04 11:47:52 -07:00
|
|
|
d += s.size() + 1;
|
|
|
|
}
|
|
|
|
}
|
2024-12-01 12:03:35 -08:00
|
|
|
sections[i] = &InputSection::discarded;
|
2022-08-04 11:47:52 -07:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2024-12-01 12:03:35 -08:00
|
|
|
switch (ctx.arg.emachine) {
|
|
|
|
case EM_ARM:
|
|
|
|
if (sec.sh_type == SHT_ARM_ATTRIBUTES) {
|
|
|
|
ARMAttributeParser attributes;
|
|
|
|
ArrayRef<uint8_t> contents =
|
|
|
|
check(this->getObj().getSectionContents(sec));
|
|
|
|
StringRef name = check(obj.getSectionName(sec, shstrtab));
|
|
|
|
sections[i] = &InputSection::discarded;
|
|
|
|
if (Error e = attributes.parse(contents, ekind == ELF32LEKind
|
|
|
|
? llvm::endianness::little
|
|
|
|
: llvm::endianness::big)) {
|
|
|
|
InputSection isec(*this, sec, name);
|
|
|
|
Warn(ctx) << &isec << ": " << std::move(e);
|
|
|
|
} else {
|
|
|
|
updateSupportedARMFeatures(ctx, attributes);
|
|
|
|
updateARMVFPArgs(ctx, attributes, this);
|
|
|
|
|
|
|
|
// FIXME: Retain the first attribute section we see. The eglibc ARM
|
|
|
|
// dynamic loaders require the presence of an attribute section for
|
|
|
|
// dlopen to work. In a full implementation we would merge all
|
|
|
|
// attribute sections.
|
|
|
|
if (ctx.in.attributes == nullptr) {
|
|
|
|
ctx.in.attributes =
|
|
|
|
std::make_unique<InputSection>(*this, sec, name);
|
|
|
|
sections[i] = ctx.in.attributes.get();
|
|
|
|
}
|
2022-08-04 11:47:52 -07:00
|
|
|
}
|
|
|
|
}
|
2024-12-01 12:03:35 -08:00
|
|
|
break;
|
|
|
|
case EM_AARCH64:
|
2025-02-05 19:04:21 +00:00
|
|
|
// FIXME: BuildAttributes have been implemented in llvm, but not yet in
|
|
|
|
// lld. Remove the section so that it does not accumulate in the output
|
|
|
|
// file. When support is implemented we expect not to output a build
|
|
|
|
// attributes section in files of type ET_EXEC or ET_SHARED, but ld -r
|
|
|
|
// ouptut will need a single merged attributes section.
|
|
|
|
if (sec.sh_type == SHT_AARCH64_ATTRIBUTES)
|
|
|
|
sections[i] = &InputSection::discarded;
|
2024-12-01 12:03:35 -08:00
|
|
|
// Producing a static binary with MTE globals is not currently supported,
|
|
|
|
// remove all SHT_AARCH64_MEMTAG_GLOBALS_STATIC sections as they're unused
|
|
|
|
// medatada, and we don't want them to end up in the output file for
|
|
|
|
// static executables.
|
|
|
|
if (sec.sh_type == SHT_AARCH64_MEMTAG_GLOBALS_STATIC &&
|
|
|
|
!canHaveMemtagGlobals(ctx))
|
|
|
|
sections[i] = &InputSection::discarded;
|
|
|
|
break;
|
2022-08-04 11:47:52 -07:00
|
|
|
}
|
|
|
|
}
|
2018-03-30 01:15:36 +00:00
|
|
|
|
|
|
|
// Read a symbol table.
|
2022-01-29 16:51:00 -08:00
|
|
|
initializeSymbols(obj);
|
2015-07-24 21:03:07 +00:00
|
|
|
}
|
|
|
|
|
2015-12-24 08:41:12 +00:00
|
|
|
// Sections with SHT_GROUP and comdat bits define comdat section groups.
|
|
|
|
// They are identified and deduplicated by group name. This function
|
|
|
|
// returns a group name.
|
2015-10-09 19:25:07 +00:00
|
|
|
template <class ELFT>
|
2017-07-26 22:13:32 +00:00
|
|
|
StringRef ObjFile<ELFT>::getShtGroupSignature(ArrayRef<Elf_Shdr> sections,
|
|
|
|
const Elf_Shdr &sec) {
|
2019-07-15 11:47:54 +00:00
|
|
|
typename ELFT::SymRange symbols = this->getELFSyms<ELFT>();
|
|
|
|
if (sec.sh_info >= symbols.size())
|
2024-11-06 21:17:26 -08:00
|
|
|
Fatal(ctx) << this << ": invalid symbol index";
|
2019-07-15 11:47:54 +00:00
|
|
|
const typename ELFT::Sym &sym = symbols[sec.sh_info];
|
2024-11-16 11:58:10 -08:00
|
|
|
return CHECK2(sym.getName(this->stringTable), this);
|
2015-10-09 19:25:07 +00:00
|
|
|
}
|
|
|
|
|
2019-10-10 08:32:12 +00:00
|
|
|
template <class ELFT>
|
|
|
|
bool ObjFile<ELFT>::shouldMerge(const Elf_Shdr &sec, StringRef name) {
|
2018-03-27 17:09:23 +00:00
|
|
|
// On a regular link we don't merge sections if -O0 (default is -O1). This
|
|
|
|
// sometimes makes the linker significantly faster, although the output will
|
|
|
|
// be bigger.
|
|
|
|
//
|
|
|
|
// Doing the same for -r would create a problem as it would combine sections
|
|
|
|
// with different sh_entsize. One option would be to just copy every SHF_MERGE
|
|
|
|
// section as is to the output. While this would produce a valid ELF file with
|
|
|
|
// usable SHF_MERGE sections, tools like (llvm-)?dwarfdump get confused when
|
|
|
|
// they see two .debug_str. We could have separate logic for combining
|
|
|
|
// SHF_MERGE sections based both on their name and sh_entsize, but that seems
|
|
|
|
// to be more trouble than it is worth. Instead, we just use the regular (-O1)
|
|
|
|
// logic for -r.
|
2024-09-21 12:47:47 -07:00
|
|
|
if (ctx.arg.optimize == 0 && !ctx.arg.relocatable)
|
2016-04-29 16:12:29 +00:00
|
|
|
return false;
|
|
|
|
|
2016-08-03 05:28:02 +00:00
|
|
|
// A mergeable section with size 0 is useless because they don't have
|
|
|
|
// any data to merge. A mergeable string section with size 0 can be
|
|
|
|
// argued as invalid because it doesn't end with a null character.
|
|
|
|
// We'll avoid a mess by handling them as if they were non-mergeable.
|
|
|
|
if (sec.sh_size == 0)
|
|
|
|
return false;
|
|
|
|
|
2016-09-21 03:22:18 +00:00
|
|
|
// Check for sh_entsize. The ELF spec is not clear about the zero
|
|
|
|
// sh_entsize. It says that "the member [sh_entsize] contains 0 if
|
|
|
|
// the section does not hold a table of fixed-size entries". We know
|
|
|
|
// that Rust 1.13 produces a string mergeable section with a zero
|
|
|
|
// sh_entsize. Here we just accept it rather than being picky about it.
|
2017-02-24 19:52:52 +00:00
|
|
|
uint64_t entSize = sec.sh_entsize;
|
2016-09-21 03:22:18 +00:00
|
|
|
if (entSize == 0)
|
|
|
|
return false;
|
|
|
|
if (sec.sh_size % entSize)
|
2025-01-25 15:28:17 -08:00
|
|
|
ErrAlways(ctx) << this << ":(" << name << "): SHF_MERGE section size ("
|
|
|
|
<< uint64_t(sec.sh_size)
|
|
|
|
<< ") must be a multiple of sh_entsize (" << entSize << ")";
|
2020-04-02 22:10:43 -07:00
|
|
|
if (sec.sh_flags & SHF_WRITE)
|
2025-01-25 15:28:17 -08:00
|
|
|
Err(ctx) << this << ":(" << name
|
|
|
|
<< "): writable SHF_MERGE section is not supported";
|
2015-10-24 22:51:01 +00:00
|
|
|
|
2017-11-15 17:31:27 +00:00
|
|
|
return true;
|
2015-10-24 22:51:01 +00:00
|
|
|
}
|
|
|
|
|
2018-03-30 01:15:36 +00:00
|
|
|
// This is for --just-symbols.
|
|
|
|
//
|
|
|
|
// --just-symbols is a very minor feature that allows you to link your
|
|
|
|
// output against other existing program, so that if you load both your
|
|
|
|
// program and the other program into memory, your output can refer the
|
|
|
|
// other program's symbols.
|
|
|
|
//
|
|
|
|
// When the option is given, we link "just symbols". The section table is
|
|
|
|
// initialized with null pointers.
|
|
|
|
template <class ELFT> void ObjFile<ELFT>::initializeJustSymbols() {
|
2021-12-24 17:10:38 -08:00
|
|
|
sections.resize(numELFShdrs);
|
2018-03-30 01:15:36 +00:00
|
|
|
}
|
|
|
|
|
2024-03-15 09:50:23 -07:00
|
|
|
static bool isKnownSpecificSectionType(uint32_t t, uint32_t flags) {
|
|
|
|
if (SHT_LOUSER <= t && t <= SHT_HIUSER && !(flags & SHF_ALLOC))
|
|
|
|
return true;
|
|
|
|
if (SHT_LOOS <= t && t <= SHT_HIOS && !(flags & SHF_OS_NONCONFORMING))
|
|
|
|
return true;
|
|
|
|
// Allow all processor-specific types. This is different from GNU ld.
|
|
|
|
return SHT_LOPROC <= t && t <= SHT_HIPROC;
|
|
|
|
}
|
|
|
|
|
2015-10-09 19:25:07 +00:00
|
|
|
template <class ELFT>
|
2022-01-29 16:51:00 -08:00
|
|
|
void ObjFile<ELFT>::initializeSections(bool ignoreComdats,
|
|
|
|
const llvm::object::ELFFile<ELFT> &obj) {
|
2021-12-24 17:10:38 -08:00
|
|
|
ArrayRef<Elf_Shdr> objSections = getELFShdrs<ELFT>();
|
2024-11-16 11:58:10 -08:00
|
|
|
StringRef shstrtab = CHECK2(obj.getSectionStringTable(objSections), this);
|
2016-11-02 14:42:20 +00:00
|
|
|
uint64_t size = objSections.size();
|
2022-08-04 11:47:52 -07:00
|
|
|
SmallVector<ArrayRef<Elf_Word>, 0> selectedGroups;
|
2022-01-18 22:45:04 -08:00
|
|
|
for (size_t i = 0; i != size; ++i) {
|
2017-03-21 08:44:25 +00:00
|
|
|
if (this->sections[i] == &InputSection::discarded)
|
2015-10-09 19:25:07 +00:00
|
|
|
continue;
|
2017-05-26 02:17:30 +00:00
|
|
|
const Elf_Shdr &sec = objSections[i];
|
2024-03-15 09:50:23 -07:00
|
|
|
const uint32_t type = sec.sh_type;
|
2015-10-09 19:25:07 +00:00
|
|
|
|
2016-10-04 16:47:49 +00:00
|
|
|
// SHF_EXCLUDE'ed sections are discarded by the linker. However,
|
|
|
|
// if -r is given, we'll let the final link discard such sections.
|
|
|
|
// This is compatible with GNU.
|
2024-09-21 12:47:47 -07:00
|
|
|
if ((sec.sh_flags & SHF_EXCLUDE) && !ctx.arg.relocatable) {
|
2024-03-15 09:50:23 -07:00
|
|
|
if (type == SHT_LLVM_CALL_GRAPH_PROFILE)
|
2021-12-12 20:05:21 -08:00
|
|
|
cgProfileSectionIndex = i;
|
2024-03-15 09:50:23 -07:00
|
|
|
if (type == SHT_LLVM_ADDRSIG) {
|
2018-07-18 22:49:31 +00:00
|
|
|
// We ignore the address-significance table if we know that the object
|
|
|
|
// file was created by objcopy or ld -r. This is because these tools
|
|
|
|
// will reorder the symbols in the symbol table, invalidating the data
|
|
|
|
// in the address-significance table, which refers to symbols by index.
|
|
|
|
if (sec.sh_link != 0)
|
|
|
|
this->addrsigSec = &sec;
|
2024-09-21 12:47:47 -07:00
|
|
|
else if (ctx.arg.icf == ICFLevel::Safe)
|
2024-11-06 22:19:31 -08:00
|
|
|
Warn(ctx) << this
|
|
|
|
<< ": --icf=safe conservatively ignores "
|
|
|
|
"SHT_LLVM_ADDRSIG [index "
|
2024-11-24 12:13:01 -08:00
|
|
|
<< i
|
2024-11-06 22:19:31 -08:00
|
|
|
<< "] with sh_link=0 "
|
|
|
|
"(likely created using objcopy or ld -r)";
|
2018-07-18 22:49:31 +00:00
|
|
|
}
|
2017-03-21 08:44:25 +00:00
|
|
|
this->sections[i] = &InputSection::discarded;
|
2016-09-28 08:42:02 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2024-03-15 09:50:23 -07:00
|
|
|
switch (type) {
|
2017-05-29 08:37:50 +00:00
|
|
|
case SHT_GROUP: {
|
2024-09-21 12:47:47 -07:00
|
|
|
if (!ctx.arg.relocatable)
|
2022-08-04 11:47:52 -07:00
|
|
|
sections[i] = &InputSection::discarded;
|
|
|
|
StringRef signature =
|
|
|
|
cantFail(this->getELFSyms<ELFT>()[sec.sh_info].getName(stringTable));
|
2019-01-24 17:56:08 +00:00
|
|
|
ArrayRef<Elf_Word> entries =
|
2022-08-04 11:47:52 -07:00
|
|
|
cantFail(obj.template getSectionContentsAsArray<Elf_Word>(sec));
|
|
|
|
if ((entries[0] & GRP_COMDAT) == 0 || ignoreComdats ||
|
2024-09-23 10:33:43 -07:00
|
|
|
ctx.symtab->comdatGroups.find(CachedHashStringRef(signature))
|
|
|
|
->second == this)
|
2019-11-18 21:56:58 -08:00
|
|
|
selectedGroups.push_back(entries);
|
2015-10-09 19:25:07 +00:00
|
|
|
break;
|
2017-05-29 08:37:50 +00:00
|
|
|
}
|
2016-03-03 16:21:44 +00:00
|
|
|
case SHT_SYMTAB_SHNDX:
|
2024-11-16 11:58:10 -08:00
|
|
|
shndxTable = CHECK2(obj.getSHNDXTable(sec, objSections), this);
|
2015-08-24 21:43:25 +00:00
|
|
|
break;
|
2019-05-28 05:17:21 +00:00
|
|
|
case SHT_SYMTAB:
|
2015-08-13 14:45:44 +00:00
|
|
|
case SHT_STRTAB:
|
2020-07-09 13:08:13 +03:00
|
|
|
case SHT_REL:
|
|
|
|
case SHT_RELA:
|
2024-08-01 10:22:03 -07:00
|
|
|
case SHT_CREL:
|
2015-08-13 14:45:44 +00:00
|
|
|
case SHT_NULL:
|
2015-08-27 23:15:56 +00:00
|
|
|
break;
|
2024-03-15 09:50:23 -07:00
|
|
|
case SHT_PROGBITS:
|
|
|
|
case SHT_NOTE:
|
|
|
|
case SHT_NOBITS:
|
|
|
|
case SHT_INIT_ARRAY:
|
|
|
|
case SHT_FINI_ARRAY:
|
|
|
|
case SHT_PREINIT_ARRAY:
|
|
|
|
this->sections[i] =
|
|
|
|
createInputSection(i, sec, check(obj.getSectionName(sec, shstrtab)));
|
|
|
|
break;
|
2024-06-07 17:56:35 -07:00
|
|
|
case SHT_LLVM_LTO:
|
|
|
|
// Discard .llvm.lto in a relocatable link that does not use the bitcode.
|
|
|
|
// The concatenated output does not properly reflect the linking
|
|
|
|
// semantics. In addition, since we do not use the bitcode wrapper format,
|
|
|
|
// the concatenated raw bitcode would be invalid.
|
2024-09-21 12:47:47 -07:00
|
|
|
if (ctx.arg.relocatable && !ctx.arg.fatLTOObjects) {
|
2024-06-07 17:56:35 -07:00
|
|
|
sections[i] = &InputSection::discarded;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
[[fallthrough]];
|
2015-11-21 22:19:32 +00:00
|
|
|
default:
|
2022-01-29 16:52:32 -08:00
|
|
|
this->sections[i] =
|
|
|
|
createInputSection(i, sec, check(obj.getSectionName(sec, shstrtab)));
|
2024-03-15 09:50:23 -07:00
|
|
|
if (type == SHT_LLVM_SYMPART)
|
|
|
|
ctx.hasSympart.store(true, std::memory_order_relaxed);
|
2024-09-21 12:47:47 -07:00
|
|
|
else if (ctx.arg.rejectMismatch &&
|
2024-03-15 09:50:23 -07:00
|
|
|
!isKnownSpecificSectionType(type, sec.sh_flags))
|
2024-11-06 22:33:51 -08:00
|
|
|
Err(ctx) << this->sections[i] << ": unknown section type 0x"
|
|
|
|
<< Twine::utohexstr(type);
|
2024-03-15 09:50:23 -07:00
|
|
|
break;
|
2015-07-24 21:03:07 +00:00
|
|
|
}
|
2019-07-18 16:47:29 +00:00
|
|
|
}
|
|
|
|
|
2020-07-09 13:08:13 +03:00
|
|
|
// We have a second loop. It is used to:
|
|
|
|
// 1) handle SHF_LINK_ORDER sections.
|
2024-03-20 09:58:56 -07:00
|
|
|
// 2) create relocation sections. In some cases the section header index of a
|
2020-07-09 13:08:13 +03:00
|
|
|
// relocation section may be smaller than that of the relocated section. In
|
|
|
|
// such cases, the relocation section would attempt to reference a target
|
|
|
|
// section that has not yet been created. For simplicity, delay creation of
|
|
|
|
// relocation sections until now.
|
2022-01-18 22:45:04 -08:00
|
|
|
for (size_t i = 0; i != size; ++i) {
|
2019-07-18 16:47:29 +00:00
|
|
|
if (this->sections[i] == &InputSection::discarded)
|
|
|
|
continue;
|
|
|
|
const Elf_Shdr &sec = objSections[i];
|
2020-07-09 13:08:13 +03:00
|
|
|
|
2024-03-20 09:58:56 -07:00
|
|
|
if (isStaticRelSecType(sec.sh_type)) {
|
2022-01-18 23:31:51 -08:00
|
|
|
// Find a relocation target section and associate this section with that.
|
|
|
|
// Target may have been discarded if it is in a different section group
|
|
|
|
// and the group is discarded, even though it's a violation of the spec.
|
|
|
|
// We handle that situation gracefully by discarding dangling relocation
|
|
|
|
// sections.
|
|
|
|
const uint32_t info = sec.sh_info;
|
2024-06-25 13:49:51 +03:00
|
|
|
InputSectionBase *s = getRelocTarget(i, info);
|
2022-01-18 23:31:51 -08:00
|
|
|
if (!s)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// ELF spec allows mergeable sections with relocations, but they are rare,
|
|
|
|
// and it is in practice hard to merge such sections by contents, because
|
|
|
|
// applying relocations at end of linking changes section contents. So, we
|
|
|
|
// simply handle such sections as non-mergeable ones. Degrading like this
|
|
|
|
// is acceptable because section merging is optional.
|
|
|
|
if (auto *ms = dyn_cast<MergeInputSection>(s)) {
|
2024-11-23 14:22:24 -08:00
|
|
|
s = makeThreadLocal<InputSection>(ms->file, ms->name, ms->type,
|
2024-11-23 14:32:32 -08:00
|
|
|
ms->flags, ms->addralign, ms->entsize,
|
2024-11-23 14:22:24 -08:00
|
|
|
ms->contentMaybeDecompress());
|
2022-01-18 23:31:51 -08:00
|
|
|
sections[info] = s;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (s->relSecIdx != 0)
|
2024-11-06 22:04:52 -08:00
|
|
|
ErrAlways(ctx) << s
|
|
|
|
<< ": multiple relocation sections to one section are "
|
|
|
|
"not supported";
|
2022-01-18 23:31:51 -08:00
|
|
|
s->relSecIdx = i;
|
|
|
|
|
|
|
|
// Relocation sections are usually removed from the output, so return
|
|
|
|
// `nullptr` for the normal case. However, if -r or --emit-relocs is
|
|
|
|
// specified, we need to copy them to the output. (Some post link analysis
|
|
|
|
// tools specify --emit-relocs to obtain the information.)
|
2024-09-21 12:47:47 -07:00
|
|
|
if (ctx.arg.copyRelocs) {
|
2022-08-04 11:47:52 -07:00
|
|
|
auto *isec = makeThreadLocal<InputSection>(
|
2022-01-18 23:31:51 -08:00
|
|
|
*this, sec, check(obj.getSectionName(sec, shstrtab)));
|
|
|
|
// If the relocated section is discarded (due to /DISCARD/ or
|
|
|
|
// --gc-sections), the relocation section should be discarded as well.
|
|
|
|
s->dependentSections.push_back(isec);
|
|
|
|
sections[i] = isec;
|
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
2020-07-09 13:08:13 +03:00
|
|
|
|
[ELF] Allow SHF_LINK_ORDER sections to have sh_link=0
Part of https://bugs.llvm.org/show_bug.cgi?id=41734
The semantics of SHF_LINK_ORDER have been extended to represent metadata
sections associated with some other sections (usually text).
The associated text section may be discarded (e.g. LTO) and we want the
metadata section to have sh_link=0 (D72899, D76802).
Normally the metadata section is only referenced by the associated text
section. sh_link=0 means the associated text section is discarded, and
the metadata section will be garbage collected. If there is another
section (.gc_root) referencing the metadata section, the metadata
section will be retained. It's the .gc_root consumer's job to validate
the metadata sections.
# This creates a SHF_LINK_ORDER .meta with sh_link=0
.section .meta,"awo",@progbits,0
1:
.section .meta,"awo",@progbits,foo
2:
.section .gc_root,"a",@progbits
.quad 1b
.quad 2b
Reviewed By: pcc, jhenderson
Differential Revision: https://reviews.llvm.org/D72904
2020-08-05 16:09:41 -07:00
|
|
|
// A SHF_LINK_ORDER section with sh_link=0 is handled as if it did not have
|
|
|
|
// the flag.
|
2022-01-18 23:31:51 -08:00
|
|
|
if (!sec.sh_link || !(sec.sh_flags & SHF_LINK_ORDER))
|
2019-07-18 16:47:29 +00:00
|
|
|
continue;
|
2015-07-24 21:03:07 +00:00
|
|
|
|
2019-07-18 16:47:29 +00:00
|
|
|
InputSectionBase *linkSec = nullptr;
|
2022-01-18 22:45:04 -08:00
|
|
|
if (sec.sh_link < size)
|
2019-07-18 16:47:29 +00:00
|
|
|
linkSec = this->sections[sec.sh_link];
|
2025-01-25 18:13:42 -08:00
|
|
|
if (!linkSec) {
|
|
|
|
ErrAlways(ctx) << this
|
|
|
|
<< ": invalid sh_link index: " << uint32_t(sec.sh_link);
|
|
|
|
continue;
|
|
|
|
}
|
2019-07-18 16:47:29 +00:00
|
|
|
|
[ELF] Allow SHF_LINK_ORDER sections to have sh_link=0
Part of https://bugs.llvm.org/show_bug.cgi?id=41734
The semantics of SHF_LINK_ORDER have been extended to represent metadata
sections associated with some other sections (usually text).
The associated text section may be discarded (e.g. LTO) and we want the
metadata section to have sh_link=0 (D72899, D76802).
Normally the metadata section is only referenced by the associated text
section. sh_link=0 means the associated text section is discarded, and
the metadata section will be garbage collected. If there is another
section (.gc_root) referencing the metadata section, the metadata
section will be retained. It's the .gc_root consumer's job to validate
the metadata sections.
# This creates a SHF_LINK_ORDER .meta with sh_link=0
.section .meta,"awo",@progbits,0
1:
.section .meta,"awo",@progbits,foo
2:
.section .gc_root,"a",@progbits
.quad 1b
.quad 2b
Reviewed By: pcc, jhenderson
Differential Revision: https://reviews.llvm.org/D72904
2020-08-05 16:09:41 -07:00
|
|
|
// A SHF_LINK_ORDER section is discarded if its linked-to section is
|
|
|
|
// discarded.
|
2019-07-18 16:47:29 +00:00
|
|
|
InputSection *isec = cast<InputSection>(this->sections[i]);
|
|
|
|
linkSec->dependentSections.push_back(isec);
|
|
|
|
if (!isa<InputSection>(linkSec))
|
2024-11-06 22:04:52 -08:00
|
|
|
ErrAlways(ctx)
|
|
|
|
<< "a section " << isec->name
|
|
|
|
<< " with SHF_LINK_ORDER should not refer a non-regular section: "
|
|
|
|
<< linkSec;
|
2016-10-10 10:10:27 +00:00
|
|
|
}
|
2019-11-18 21:56:58 -08:00
|
|
|
|
2019-12-06 16:26:55 -08:00
|
|
|
for (ArrayRef<Elf_Word> entries : selectedGroups)
|
|
|
|
handleSectionGroup<ELFT>(this->sections, entries);
|
2016-10-10 10:10:27 +00:00
|
|
|
}
|
|
|
|
|
[AArch64][GCS][LLD] Introduce -zgcs-report-dynamic Command Line Option (#127787)
When GCS was introduced to LLD, the gcs-report option allowed for a user
to gain information relating to if their relocatable objects supported
the feature. For an executable or shared-library to support GCS, all
relocatable objects must declare that they support GCS.
The gcs-report checks were only done on relocatable object files,
however for a program to enable GCS, the executable and all shared
libraries that it loads must enable GCS. gcs-report-dynamic enables
checks to be performed on all shared objects loaded by LLD, and in cases
where GCS is not supported, a warning or error will be emitted.
It should be noted that only shared files directly passed to LLD are
checked for GCS support. Files that are noted in the `DT_NEEDED` tags
are assumed to have had their GCS support checked when they were
created.
The behaviour of the -zgcs-dynamic-report option matches that of GNU ld.
The behaviour is as follows unless the user explicitly sets the value:
* -zgcs-report=warning or -zgcs-report=error implies
-zgcs-report-dynamic=warning.
This approach avoids inheriting an error level if the user wishes to
continue building a module without rebuilding all the shared libraries.
The same approach was taken for the GNU ld linker, so behaviour is
identical across the toolchains.
This implementation matches the error message and command line interface
used within the GNU ld Linker. See here:
https://github.com/bminor/binutils-gdb/commit/724a8341f6491283cf90038260c83a454b7268ef
To support this option being introduced, two other changes are included
as part of this PR. The first converts the -zgcs-report option to
utilise an Enum, opposed to StringRef values. This enables easier
tracking of the value the user defines when inheriting the value for the
gas-report-dynamic option. The second is to parse the Dynamic Objects
program headers to locate the GNU Attribute flag that shows GCS is
supported. This is needed so, when using the gcs-report-dynamic option,
LLD can correctly determine if a dynamic object supports GCS.
---------
Co-authored-by: Fangrui Song <i@maskray.me>
2025-03-16 01:15:05 +00:00
|
|
|
template <typename ELFT>
|
|
|
|
static void parseGnuPropertyNote(Ctx &ctx, ELFFileBase &f,
|
|
|
|
uint32_t featureAndType,
|
|
|
|
ArrayRef<uint8_t> &desc, const uint8_t *base,
|
|
|
|
ArrayRef<uint8_t> *data = nullptr) {
|
|
|
|
auto err = [&](const uint8_t *place) -> ELFSyncStream {
|
|
|
|
auto diag = Err(ctx);
|
|
|
|
diag << &f << ":(" << ".note.gnu.property+0x"
|
|
|
|
<< Twine::utohexstr(place - base) << "): ";
|
|
|
|
return diag;
|
|
|
|
};
|
|
|
|
|
|
|
|
while (!desc.empty()) {
|
|
|
|
const uint8_t *place = desc.data();
|
|
|
|
if (desc.size() < 8)
|
|
|
|
return void(err(place) << "program property is too short");
|
|
|
|
uint32_t type = read32<ELFT::Endianness>(desc.data());
|
|
|
|
uint32_t size = read32<ELFT::Endianness>(desc.data() + 4);
|
|
|
|
desc = desc.slice(8);
|
|
|
|
if (desc.size() < size)
|
|
|
|
return void(err(place) << "program property is too short");
|
|
|
|
|
|
|
|
if (type == featureAndType) {
|
|
|
|
// We found a FEATURE_1_AND field. There may be more than one of these
|
|
|
|
// in a .note.gnu.property section, for a relocatable object we
|
|
|
|
// accumulate the bits set.
|
|
|
|
if (size < 4)
|
|
|
|
return void(err(place) << "FEATURE_1_AND entry is too short");
|
|
|
|
f.andFeatures |= read32<ELFT::Endianness>(desc.data());
|
|
|
|
} else if (ctx.arg.emachine == EM_AARCH64 &&
|
|
|
|
type == GNU_PROPERTY_AARCH64_FEATURE_PAUTH) {
|
|
|
|
ArrayRef<uint8_t> contents = data ? *data : desc;
|
|
|
|
if (!f.aarch64PauthAbiCoreInfo.empty()) {
|
|
|
|
return void(
|
|
|
|
err(contents.data())
|
|
|
|
<< "multiple GNU_PROPERTY_AARCH64_FEATURE_PAUTH entries are "
|
|
|
|
"not supported");
|
|
|
|
} else if (size != 16) {
|
|
|
|
return void(err(contents.data())
|
|
|
|
<< "GNU_PROPERTY_AARCH64_FEATURE_PAUTH entry "
|
|
|
|
"is invalid: expected 16 bytes, but got "
|
|
|
|
<< size);
|
|
|
|
}
|
|
|
|
f.aarch64PauthAbiCoreInfo = desc;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Padding is present in the note descriptor, if necessary.
|
|
|
|
desc = desc.slice(alignTo<(ELFT::Is64Bits ? 8 : 4)>(size));
|
|
|
|
}
|
|
|
|
}
|
2024-04-04 12:38:09 +03:00
|
|
|
// Read the following info from the .note.gnu.property section and write it to
|
|
|
|
// the corresponding fields in `ObjFile`:
|
|
|
|
// - Feature flags (32 bits) representing x86 or AArch64 features for
|
|
|
|
// hardware-assisted call flow control;
|
|
|
|
// - AArch64 PAuth ABI core info (16 bytes).
|
|
|
|
template <class ELFT>
|
2024-10-06 18:09:52 -07:00
|
|
|
static void readGnuProperty(Ctx &ctx, const InputSection &sec,
|
|
|
|
ObjFile<ELFT> &f) {
|
2019-06-05 03:04:46 +00:00
|
|
|
using Elf_Nhdr = typename ELFT::Nhdr;
|
|
|
|
using Elf_Note = typename ELFT::Note;
|
|
|
|
|
2022-11-20 22:43:22 +00:00
|
|
|
ArrayRef<uint8_t> data = sec.content();
|
2025-01-25 17:29:28 -08:00
|
|
|
auto err = [&](const uint8_t *place) -> ELFSyncStream {
|
|
|
|
auto diag = Err(ctx);
|
|
|
|
diag << sec.file << ":(" << sec.name << "+0x"
|
|
|
|
<< Twine::utohexstr(place - sec.content().data()) << "): ";
|
|
|
|
return diag;
|
2020-08-25 08:05:38 -07:00
|
|
|
};
|
2019-06-05 03:04:46 +00:00
|
|
|
while (!data.empty()) {
|
|
|
|
// Read one NOTE record.
|
|
|
|
auto *nhdr = reinterpret_cast<const Elf_Nhdr *>(data.data());
|
2023-05-10 09:36:58 -07:00
|
|
|
if (data.size() < sizeof(Elf_Nhdr) ||
|
|
|
|
data.size() < nhdr->getSize(sec.addralign))
|
2025-01-25 17:29:28 -08:00
|
|
|
return void(err(data.data()) << "data is too short");
|
2019-06-05 03:04:46 +00:00
|
|
|
|
|
|
|
Elf_Note note(*nhdr);
|
|
|
|
if (nhdr->n_type != NT_GNU_PROPERTY_TYPE_0 || note.getName() != "GNU") {
|
2023-05-10 09:36:58 -07:00
|
|
|
data = data.slice(nhdr->getSize(sec.addralign));
|
2019-06-05 03:04:46 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2024-09-21 12:47:47 -07:00
|
|
|
uint32_t featureAndType = ctx.arg.emachine == EM_AARCH64
|
2019-06-07 13:00:17 +00:00
|
|
|
? GNU_PROPERTY_AARCH64_FEATURE_1_AND
|
|
|
|
: GNU_PROPERTY_X86_FEATURE_1_AND;
|
|
|
|
|
2019-06-05 03:04:46 +00:00
|
|
|
// Read a body of a NOTE record, which consists of type-length-value fields.
|
2023-05-10 09:36:58 -07:00
|
|
|
ArrayRef<uint8_t> desc = note.getDesc(sec.addralign);
|
[AArch64][GCS][LLD] Introduce -zgcs-report-dynamic Command Line Option (#127787)
When GCS was introduced to LLD, the gcs-report option allowed for a user
to gain information relating to if their relocatable objects supported
the feature. For an executable or shared-library to support GCS, all
relocatable objects must declare that they support GCS.
The gcs-report checks were only done on relocatable object files,
however for a program to enable GCS, the executable and all shared
libraries that it loads must enable GCS. gcs-report-dynamic enables
checks to be performed on all shared objects loaded by LLD, and in cases
where GCS is not supported, a warning or error will be emitted.
It should be noted that only shared files directly passed to LLD are
checked for GCS support. Files that are noted in the `DT_NEEDED` tags
are assumed to have had their GCS support checked when they were
created.
The behaviour of the -zgcs-dynamic-report option matches that of GNU ld.
The behaviour is as follows unless the user explicitly sets the value:
* -zgcs-report=warning or -zgcs-report=error implies
-zgcs-report-dynamic=warning.
This approach avoids inheriting an error level if the user wishes to
continue building a module without rebuilding all the shared libraries.
The same approach was taken for the GNU ld linker, so behaviour is
identical across the toolchains.
This implementation matches the error message and command line interface
used within the GNU ld Linker. See here:
https://github.com/bminor/binutils-gdb/commit/724a8341f6491283cf90038260c83a454b7268ef
To support this option being introduced, two other changes are included
as part of this PR. The first converts the -zgcs-report option to
utilise an Enum, opposed to StringRef values. This enables easier
tracking of the value the user defines when inheriting the value for the
gas-report-dynamic option. The second is to parse the Dynamic Objects
program headers to locate the GNU Attribute flag that shows GCS is
supported. This is needed so, when using the gcs-report-dynamic option,
LLD can correctly determine if a dynamic object supports GCS.
---------
Co-authored-by: Fangrui Song <i@maskray.me>
2025-03-16 01:15:05 +00:00
|
|
|
const uint8_t *base = sec.content().data();
|
|
|
|
parseGnuPropertyNote<ELFT>(ctx, f, featureAndType, desc, base, &data);
|
2019-06-05 03:04:46 +00:00
|
|
|
|
2019-06-05 09:31:45 +00:00
|
|
|
// Go to next NOTE record to look for more FEATURE_1_AND descriptions.
|
2023-05-10 09:36:58 -07:00
|
|
|
data = data.slice(nhdr->getSize(sec.addralign));
|
2019-06-05 03:04:46 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-03-13 21:52:57 +00:00
|
|
|
template <class ELFT>
|
2024-06-25 13:49:51 +03:00
|
|
|
InputSectionBase *ObjFile<ELFT>::getRelocTarget(uint32_t idx, uint32_t info) {
|
2021-11-09 09:54:12 -08:00
|
|
|
if (info < this->sections.size()) {
|
|
|
|
InputSectionBase *target = this->sections[info];
|
|
|
|
|
|
|
|
// Strictly speaking, a relocation section must be included in the
|
|
|
|
// group of the section it relocates. However, LLVM 3.3 and earlier
|
|
|
|
// would fail to do so, so we gracefully handle that case.
|
|
|
|
if (target == &InputSection::discarded)
|
|
|
|
return nullptr;
|
2016-03-13 21:52:57 +00:00
|
|
|
|
2021-11-09 09:54:12 -08:00
|
|
|
if (target != nullptr)
|
|
|
|
return target;
|
|
|
|
}
|
2016-03-13 21:52:57 +00:00
|
|
|
|
2024-11-16 20:32:44 -08:00
|
|
|
Err(ctx) << this << ": relocation section (index " << idx
|
|
|
|
<< ") has invalid sh_info (" << info << ')';
|
2021-11-09 09:54:12 -08:00
|
|
|
return nullptr;
|
2016-03-13 21:52:57 +00:00
|
|
|
}
|
|
|
|
|
2022-08-04 11:47:52 -07:00
|
|
|
// The function may be called concurrently for different input files. For
|
|
|
|
// allocation, prefer makeThreadLocal which does not require holding a lock.
|
2016-02-12 21:17:10 +00:00
|
|
|
template <class ELFT>
|
2022-01-29 16:52:32 -08:00
|
|
|
InputSectionBase *ObjFile<ELFT>::createInputSection(uint32_t idx,
|
|
|
|
const Elf_Shdr &sec,
|
|
|
|
StringRef name) {
|
2023-06-05 14:36:19 -07:00
|
|
|
if (name.starts_with(".n")) {
|
2021-12-15 17:15:31 -08:00
|
|
|
// The GNU linker uses .note.GNU-stack section as a marker indicating
|
|
|
|
// that the code in the object file does not expect that the stack is
|
|
|
|
// executable (in terms of NX bit). If all input files have the marker,
|
|
|
|
// the GNU linker adds a PT_GNU_STACK segment to tells the loader to
|
|
|
|
// make the stack non-executable. Most object files have this section as
|
|
|
|
// of 2017.
|
|
|
|
//
|
|
|
|
// But making the stack non-executable is a norm today for security
|
|
|
|
// reasons. Failure to do so may result in a serious security issue.
|
|
|
|
// Therefore, we make LLD always add PT_GNU_STACK unless it is
|
|
|
|
// explicitly told to do otherwise (by -z execstack). Because the stack
|
|
|
|
// executable-ness is controlled solely by command line options,
|
2025-01-23 12:32:54 -05:00
|
|
|
// .note.GNU-stack sections are, with one exception, ignored. Report
|
|
|
|
// an error if we encounter an executable .note.GNU-stack to force the
|
|
|
|
// user to explicitly request an executable stack.
|
|
|
|
if (name == ".note.GNU-stack") {
|
|
|
|
if ((sec.sh_flags & SHF_EXECINSTR) && !ctx.arg.relocatable &&
|
|
|
|
ctx.arg.zGnustack != GnuStackKind::Exec) {
|
|
|
|
Err(ctx) << this
|
|
|
|
<< ": requires an executable stack, but -z execstack is not "
|
|
|
|
"specified";
|
|
|
|
}
|
2021-12-15 17:15:31 -08:00
|
|
|
return &InputSection::discarded;
|
2025-01-23 12:32:54 -05:00
|
|
|
}
|
2015-12-24 08:41:12 +00:00
|
|
|
|
2021-12-15 17:15:31 -08:00
|
|
|
// Object files that use processor features such as Intel Control-Flow
|
|
|
|
// Enforcement (CET) or AArch64 Branch Target Identification BTI, use a
|
|
|
|
// .note.gnu.property section containing a bitfield of feature bits like the
|
|
|
|
// GNU_PROPERTY_X86_FEATURE_1_IBT flag. Read a bitmap containing the flag.
|
|
|
|
//
|
|
|
|
// Since we merge bitmaps from multiple object files to create a new
|
|
|
|
// .note.gnu.property containing a single AND'ed bitmap, we discard an input
|
|
|
|
// file's .note.gnu.property section.
|
|
|
|
if (name == ".note.gnu.property") {
|
2024-10-06 18:09:52 -07:00
|
|
|
readGnuProperty<ELFT>(ctx, InputSection(*this, sec, name), *this);
|
2021-12-15 17:15:31 -08:00
|
|
|
return &InputSection::discarded;
|
|
|
|
}
|
2019-06-05 03:04:46 +00:00
|
|
|
|
2021-12-15 17:15:31 -08:00
|
|
|
// Split stacks is a feature to support a discontiguous stack,
|
|
|
|
// commonly used in the programming language Go. For the details,
|
|
|
|
// see https://gcc.gnu.org/wiki/SplitStacks. An object file compiled
|
|
|
|
// for split stack will include a .note.GNU-split-stack section.
|
|
|
|
if (name == ".note.GNU-split-stack") {
|
2024-09-21 12:47:47 -07:00
|
|
|
if (ctx.arg.relocatable) {
|
2024-11-06 22:04:52 -08:00
|
|
|
ErrAlways(ctx) << "cannot mix split-stack and non-split-stack in a "
|
|
|
|
"relocatable link";
|
2021-12-15 17:15:31 -08:00
|
|
|
return &InputSection::discarded;
|
|
|
|
}
|
|
|
|
this->splitStack = true;
|
2018-07-17 23:16:02 +00:00
|
|
|
return &InputSection::discarded;
|
|
|
|
}
|
|
|
|
|
2022-08-02 09:52:31 -04:00
|
|
|
// An object file compiled for split stack, but where some of the
|
2021-12-15 17:15:31 -08:00
|
|
|
// functions were compiled with the no_split_stack_attribute will
|
|
|
|
// include a .note.GNU-no-split-stack section.
|
|
|
|
if (name == ".note.GNU-no-split-stack") {
|
|
|
|
this->someNoSplitStack = true;
|
|
|
|
return &InputSection::discarded;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Strip existing .note.gnu.build-id sections so that the output won't have
|
|
|
|
// more than one build-id. This is not usually a problem because input
|
|
|
|
// object files normally don't have .build-id sections, but you can create
|
|
|
|
// such files by "ld.{bfd,gold,lld} -r --build-id", and we want to guard
|
|
|
|
// against it.
|
|
|
|
if (name == ".note.gnu.build-id")
|
|
|
|
return &InputSection::discarded;
|
2016-04-07 21:04:51 +00:00
|
|
|
}
|
|
|
|
|
2016-07-15 04:57:44 +00:00
|
|
|
// The linker merges EH (exception handling) frames and creates a
|
|
|
|
// .eh_frame_hdr section for runtime. So we handle them with a special
|
|
|
|
// class. For relocatable outputs, they are just passed through.
|
2024-09-21 12:47:47 -07:00
|
|
|
if (name == ".eh_frame" && !ctx.arg.relocatable)
|
2022-08-04 11:47:52 -07:00
|
|
|
return makeThreadLocal<EhInputSection>(*this, sec, name);
|
2016-07-15 04:57:44 +00:00
|
|
|
|
2021-12-15 17:15:31 -08:00
|
|
|
if ((sec.sh_flags & SHF_MERGE) && shouldMerge(sec, name))
|
2022-08-04 11:47:52 -07:00
|
|
|
return makeThreadLocal<MergeInputSection>(*this, sec, name);
|
|
|
|
return makeThreadLocal<InputSection>(*this, sec, name);
|
2015-12-24 08:41:12 +00:00
|
|
|
}
|
|
|
|
|
[LLD][ELF] Cortex-M Security Extensions (CMSE) Support
This commit provides linker support for Cortex-M Security Extensions (CMSE).
The specification for this feature can be found in ARM v8-M Security Extensions:
Requirements on Development Tools.
The linker synthesizes a security gateway veneer in a special section;
`.gnu.sgstubs`, when it finds non-local symbols `__acle_se_<entry>` and `<entry>`,
defined relative to the same text section and having the same address. The
address of `<entry>` is retargeted to the starting address of the
linker-synthesized security gateway veneer in section `.gnu.sgstubs`.
In summary, the linker translates input:
```
.text
entry:
__acle_se_entry:
[entry_code]
```
into:
```
.section .gnu.sgstubs
entry:
SG
B.W __acle_se_entry
.text
__acle_se_entry:
[entry_code]
```
If addresses of `__acle_se_<entry>` and `<entry>` are not equal, the linker
considers that `<entry>` already defines a secure gateway veneer so does not
synthesize one.
If `--out-implib=<out.lib>` is specified, the linker writes the list of secure
gateway veneers into a CMSE import library `<out.lib>`. The CMSE import library
will have 3 sections: `.symtab`, `.strtab`, `.shstrtab`. For every secure gateway
veneer <entry> at address `<addr>`, `.symtab` contains a `SHN_ABS` symbol `<entry>` with
value `<addr>`.
If `--in-implib=<in.lib>` is specified, the linker reads the existing CMSE import
library `<in.lib>` and preserves the entry function addresses in the resulting
executable and new import library.
Reviewed By: MaskRay, peter.smith
Differential Revision: https://reviews.llvm.org/D139092
2023-07-06 10:45:10 +01:00
|
|
|
// Initialize symbols. symbols is a parallel array to the corresponding ELF
|
|
|
|
// symbol table.
|
2022-01-29 16:51:00 -08:00
|
|
|
template <class ELFT>
|
|
|
|
void ObjFile<ELFT>::initializeSymbols(const object::ELFFile<ELFT> &obj) {
|
Speed up --start-lib and --end-lib.
--{start,end}-lib give files grouped by the options the archive file
semantics. That is, each object file between them acts as if it were
in an archive file whose sole member is the file.
Therefore, files between --{start,end}-lib are linked to the final
output only if they are needed to resolve some undefined symbols.
Previously, the feature was implemented this way:
1. We read a symbol table and insert defined symbols to the symbol
table as lazy symbols.
2. If an undefind symbol is resolved to a lazy symbol, that lazy
symbol instantiate ObjFile class for that symbol, which re-insert
all defined symbols to the symbol table.
So, if an ObjFile is instantiated, defined symbols are inserted to the
symbol table twice. Since inserting long symbol names is not cheap,
there's a room to optimize here.
This patch optimzies it. Now, LazyObjFile remembers symbol handles and
passed them over to a new ObjFile instance, so that the ObjFile
doesn't insert the same strings.
Here is a quick benchmark to link clang. "Original" is the original
lld with unmodified command line options. For "Case 1" and "Case 2", I
extracted all files from archive files and replace .a's in a command
line with .o's wrapped with --{start,end}-lib. I used the original lld
for Case 1" and use this patch for Case 2.
Original: 5.892
Case 1: 6.001 (+1.8%)
Case 2: 5.701 (-3.2%)
So, interestingly, --{start,end}-lib are now faster than the regular
linking scheme with archive files. That's perhaps not too surprising,
though, because for regular archive files, we look up the symbol table
with the same string twice.
Differential Revision: https://reviews.llvm.org/D62188
llvm-svn: 361473
2019-05-23 09:53:30 +00:00
|
|
|
ArrayRef<Elf_Sym> eSyms = this->getELFSyms<ELFT>();
|
2024-12-08 15:59:03 -08:00
|
|
|
if (!symbols)
|
2022-11-21 09:02:04 +00:00
|
|
|
symbols = std::make_unique<Symbol *[]>(numSymbols);
|
2020-06-19 09:05:28 -07:00
|
|
|
|
2021-12-15 12:54:38 -08:00
|
|
|
// Some entries have been filled by LazyObjFile.
|
2024-10-06 18:09:52 -07:00
|
|
|
auto *symtab = ctx.symtab.get();
|
2021-12-15 12:54:38 -08:00
|
|
|
for (size_t i = firstGlobal, end = eSyms.size(); i != end; ++i)
|
2021-12-23 21:54:32 -08:00
|
|
|
if (!symbols[i])
|
2024-11-16 11:58:10 -08:00
|
|
|
symbols[i] = symtab->insert(CHECK2(eSyms[i].getName(stringTable), this));
|
2021-12-15 12:54:38 -08:00
|
|
|
|
|
|
|
// Perform symbol resolution on non-local symbols.
|
2021-07-19 14:38:15 -04:00
|
|
|
SmallVector<unsigned, 32> undefineds;
|
2020-06-19 09:05:28 -07:00
|
|
|
for (size_t i = firstGlobal, end = eSyms.size(); i != end; ++i) {
|
|
|
|
const Elf_Sym &eSym = eSyms[i];
|
2022-01-29 18:01:58 -08:00
|
|
|
uint32_t secIdx = eSym.st_shndx;
|
2022-02-05 15:25:23 -08:00
|
|
|
if (secIdx == SHN_UNDEF) {
|
|
|
|
undefineds.push_back(i);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2022-03-16 00:31:29 -07:00
|
|
|
uint8_t binding = eSym.getBinding();
|
Speed up --start-lib and --end-lib.
--{start,end}-lib give files grouped by the options the archive file
semantics. That is, each object file between them acts as if it were
in an archive file whose sole member is the file.
Therefore, files between --{start,end}-lib are linked to the final
output only if they are needed to resolve some undefined symbols.
Previously, the feature was implemented this way:
1. We read a symbol table and insert defined symbols to the symbol
table as lazy symbols.
2. If an undefind symbol is resolved to a lazy symbol, that lazy
symbol instantiate ObjFile class for that symbol, which re-insert
all defined symbols to the symbol table.
So, if an ObjFile is instantiated, defined symbols are inserted to the
symbol table twice. Since inserting long symbol names is not cheap,
there's a room to optimize here.
This patch optimzies it. Now, LazyObjFile remembers symbol handles and
passed them over to a new ObjFile instance, so that the ObjFile
doesn't insert the same strings.
Here is a quick benchmark to link clang. "Original" is the original
lld with unmodified command line options. For "Case 1" and "Case 2", I
extracted all files from archive files and replace .a's in a command
line with .o's wrapped with --{start,end}-lib. I used the original lld
for Case 1" and use this patch for Case 2.
Original: 5.892
Case 1: 6.001 (+1.8%)
Case 2: 5.701 (-3.2%)
So, interestingly, --{start,end}-lib are now faster than the regular
linking scheme with archive files. That's perhaps not too surprising,
though, because for regular archive files, we look up the symbol table
with the same string twice.
Differential Revision: https://reviews.llvm.org/D62188
llvm-svn: 361473
2019-05-23 09:53:30 +00:00
|
|
|
uint8_t stOther = eSym.st_other;
|
|
|
|
uint8_t type = eSym.getType();
|
|
|
|
uint64_t value = eSym.st_value;
|
|
|
|
uint64_t size = eSym.st_size;
|
|
|
|
|
2021-12-23 21:54:32 -08:00
|
|
|
Symbol *sym = symbols[i];
|
2022-02-23 21:32:50 -08:00
|
|
|
sym->isUsedInRegularObj = true;
|
2021-12-23 21:54:32 -08:00
|
|
|
if (LLVM_UNLIKELY(eSym.st_shndx == SHN_COMMON)) {
|
Speed up --start-lib and --end-lib.
--{start,end}-lib give files grouped by the options the archive file
semantics. That is, each object file between them acts as if it were
in an archive file whose sole member is the file.
Therefore, files between --{start,end}-lib are linked to the final
output only if they are needed to resolve some undefined symbols.
Previously, the feature was implemented this way:
1. We read a symbol table and insert defined symbols to the symbol
table as lazy symbols.
2. If an undefind symbol is resolved to a lazy symbol, that lazy
symbol instantiate ObjFile class for that symbol, which re-insert
all defined symbols to the symbol table.
So, if an ObjFile is instantiated, defined symbols are inserted to the
symbol table twice. Since inserting long symbol names is not cheap,
there's a room to optimize here.
This patch optimzies it. Now, LazyObjFile remembers symbol handles and
passed them over to a new ObjFile instance, so that the ObjFile
doesn't insert the same strings.
Here is a quick benchmark to link clang. "Original" is the original
lld with unmodified command line options. For "Case 1" and "Case 2", I
extracted all files from archive files and replace .a's in a command
line with .o's wrapped with --{start,end}-lib. I used the original lld
for Case 1" and use this patch for Case 2.
Original: 5.892
Case 1: 6.001 (+1.8%)
Case 2: 5.701 (-3.2%)
So, interestingly, --{start,end}-lib are now faster than the regular
linking scheme with archive files. That's perhaps not too surprising,
though, because for regular archive files, we look up the symbol table
with the same string twice.
Differential Revision: https://reviews.llvm.org/D62188
llvm-svn: 361473
2019-05-23 09:53:30 +00:00
|
|
|
if (value == 0 || value >= UINT32_MAX)
|
2025-01-26 16:13:51 -08:00
|
|
|
Err(ctx) << this << ": common symbol '" << sym->getName()
|
|
|
|
<< "' has invalid alignment: " << value;
|
2021-12-24 19:01:50 -08:00
|
|
|
hasCommonSyms = true;
|
2024-10-20 01:38:16 +00:00
|
|
|
sym->resolve(ctx, CommonSymbol{ctx, this, StringRef(), binding, stOther,
|
|
|
|
type, value, size});
|
Speed up --start-lib and --end-lib.
--{start,end}-lib give files grouped by the options the archive file
semantics. That is, each object file between them acts as if it were
in an archive file whose sole member is the file.
Therefore, files between --{start,end}-lib are linked to the final
output only if they are needed to resolve some undefined symbols.
Previously, the feature was implemented this way:
1. We read a symbol table and insert defined symbols to the symbol
table as lazy symbols.
2. If an undefind symbol is resolved to a lazy symbol, that lazy
symbol instantiate ObjFile class for that symbol, which re-insert
all defined symbols to the symbol table.
So, if an ObjFile is instantiated, defined symbols are inserted to the
symbol table twice. Since inserting long symbol names is not cheap,
there's a room to optimize here.
This patch optimzies it. Now, LazyObjFile remembers symbol handles and
passed them over to a new ObjFile instance, so that the ObjFile
doesn't insert the same strings.
Here is a quick benchmark to link clang. "Original" is the original
lld with unmodified command line options. For "Case 1" and "Case 2", I
extracted all files from archive files and replace .a's in a command
line with .o's wrapped with --{start,end}-lib. I used the original lld
for Case 1" and use this patch for Case 2.
Original: 5.892
Case 1: 6.001 (+1.8%)
Case 2: 5.701 (-3.2%)
So, interestingly, --{start,end}-lib are now faster than the regular
linking scheme with archive files. That's perhaps not too surprising,
though, because for regular archive files, we look up the symbol table
with the same string twice.
Differential Revision: https://reviews.llvm.org/D62188
llvm-svn: 361473
2019-05-23 09:53:30 +00:00
|
|
|
continue;
|
|
|
|
}
|
2019-05-22 04:56:25 +00:00
|
|
|
|
2022-03-15 19:24:41 -07:00
|
|
|
// Handle global defined symbols. Defined::section will be set in postParse.
|
2024-10-20 01:38:16 +00:00
|
|
|
sym->resolve(ctx, Defined{ctx, this, StringRef(), binding, stOther, type,
|
|
|
|
value, size, nullptr});
|
2015-10-09 19:25:07 +00:00
|
|
|
}
|
2021-02-11 09:41:46 -08:00
|
|
|
|
|
|
|
// Undefined symbols (excluding those defined relative to non-prevailing
|
2021-11-26 10:58:50 -08:00
|
|
|
// sections) can trigger recursive extract. Process defined symbols first so
|
2021-02-11 09:41:46 -08:00
|
|
|
// that the relative order between a defined symbol and an undefined symbol
|
|
|
|
// does not change the symbol resolution behavior. In addition, a set of
|
|
|
|
// interconnected symbols will all be resolved to the same file, instead of
|
|
|
|
// being resolved to different files.
|
2021-07-19 14:38:15 -04:00
|
|
|
for (unsigned i : undefineds) {
|
2021-02-11 09:41:46 -08:00
|
|
|
const Elf_Sym &eSym = eSyms[i];
|
2021-12-23 21:54:32 -08:00
|
|
|
Symbol *sym = symbols[i];
|
2024-10-11 23:34:43 -07:00
|
|
|
sym->resolve(ctx, Undefined{this, StringRef(), eSym.getBinding(),
|
|
|
|
eSym.st_other, eSym.getType()});
|
2022-02-23 21:32:50 -08:00
|
|
|
sym->isUsedInRegularObj = true;
|
2021-12-15 15:30:18 -08:00
|
|
|
sym->referenced = true;
|
2021-02-11 09:41:46 -08:00
|
|
|
}
|
2015-07-24 21:03:07 +00:00
|
|
|
}
|
|
|
|
|
2022-08-04 11:47:52 -07:00
|
|
|
template <class ELFT>
|
|
|
|
void ObjFile<ELFT>::initSectionsAndLocalSyms(bool ignoreComdats) {
|
|
|
|
if (!justSymbols)
|
|
|
|
initializeSections(ignoreComdats, getObj());
|
|
|
|
|
2022-03-04 19:00:10 -08:00
|
|
|
if (!firstGlobal)
|
|
|
|
return;
|
2022-08-04 11:09:40 -07:00
|
|
|
SymbolUnion *locals = makeThreadLocalN<SymbolUnion>(firstGlobal);
|
2022-09-28 17:56:16 -07:00
|
|
|
memset(locals, 0, sizeof(SymbolUnion) * firstGlobal);
|
2022-03-04 19:00:10 -08:00
|
|
|
|
|
|
|
ArrayRef<Elf_Sym> eSyms = this->getELFSyms<ELFT>();
|
|
|
|
for (size_t i = 0, end = firstGlobal; i != end; ++i) {
|
|
|
|
const Elf_Sym &eSym = eSyms[i];
|
|
|
|
uint32_t secIdx = eSym.st_shndx;
|
|
|
|
if (LLVM_UNLIKELY(secIdx == SHN_XINDEX))
|
|
|
|
secIdx = check(getExtendedSymbolTableIndex<ELFT>(eSym, i, shndxTable));
|
|
|
|
else if (secIdx >= SHN_LORESERVE)
|
|
|
|
secIdx = 0;
|
2025-01-25 17:29:28 -08:00
|
|
|
if (LLVM_UNLIKELY(secIdx >= sections.size())) {
|
|
|
|
Err(ctx) << this << ": invalid section index: " << secIdx;
|
|
|
|
secIdx = 0;
|
|
|
|
}
|
2022-03-04 19:00:10 -08:00
|
|
|
if (LLVM_UNLIKELY(eSym.getBinding() != STB_LOCAL))
|
2024-11-16 20:26:33 -08:00
|
|
|
ErrAlways(ctx) << this << ": non-local symbol (" << i
|
|
|
|
<< ") found at index < .symtab's sh_info (" << end << ")";
|
2022-03-04 19:00:10 -08:00
|
|
|
|
|
|
|
InputSectionBase *sec = sections[secIdx];
|
|
|
|
uint8_t type = eSym.getType();
|
|
|
|
if (type == STT_FILE)
|
2024-11-16 11:58:10 -08:00
|
|
|
sourceFile = CHECK2(eSym.getName(stringTable), this);
|
2025-01-25 17:29:28 -08:00
|
|
|
unsigned stName = eSym.st_name;
|
|
|
|
if (LLVM_UNLIKELY(stringTable.size() <= stName)) {
|
|
|
|
Err(ctx) << this << ": invalid symbol name offset";
|
|
|
|
stName = 0;
|
|
|
|
}
|
|
|
|
StringRef name(stringTable.data() + stName);
|
2022-03-04 19:00:10 -08:00
|
|
|
|
|
|
|
symbols[i] = reinterpret_cast<Symbol *>(locals + i);
|
|
|
|
if (eSym.st_shndx == SHN_UNDEF || sec == &InputSection::discarded)
|
|
|
|
new (symbols[i]) Undefined(this, name, STB_LOCAL, eSym.st_other, type,
|
|
|
|
/*discardedSecIdx=*/secIdx);
|
|
|
|
else
|
2024-10-20 01:38:16 +00:00
|
|
|
new (symbols[i]) Defined(ctx, this, name, STB_LOCAL, eSym.st_other, type,
|
2022-03-04 19:00:10 -08:00
|
|
|
eSym.st_value, eSym.st_size, sec);
|
2022-09-28 17:56:16 -07:00
|
|
|
symbols[i]->partition = 1;
|
2022-03-04 19:00:10 -08:00
|
|
|
symbols[i]->isUsedInRegularObj = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2022-02-22 10:07:58 -08:00
|
|
|
// Called after all ObjFile::parse is called for all ObjFiles. This checks
|
|
|
|
// duplicate symbols and may do symbol property merge in the future.
|
|
|
|
template <class ELFT> void ObjFile<ELFT>::postParse() {
|
2022-03-15 19:24:41 -07:00
|
|
|
static std::mutex mu;
|
2022-02-22 10:07:58 -08:00
|
|
|
ArrayRef<Elf_Sym> eSyms = this->getELFSyms<ELFT>();
|
|
|
|
for (size_t i = firstGlobal, end = eSyms.size(); i != end; ++i) {
|
|
|
|
const Elf_Sym &eSym = eSyms[i];
|
2022-03-15 19:24:41 -07:00
|
|
|
Symbol &sym = *symbols[i];
|
|
|
|
uint32_t secIdx = eSym.st_shndx;
|
2022-03-16 00:31:29 -07:00
|
|
|
uint8_t binding = eSym.getBinding();
|
|
|
|
if (LLVM_UNLIKELY(binding != STB_GLOBAL && binding != STB_WEAK &&
|
|
|
|
binding != STB_GNU_UNIQUE))
|
2024-11-16 20:26:33 -08:00
|
|
|
Err(ctx) << this << ": symbol (" << i
|
|
|
|
<< ") has invalid binding: " << (int)binding;
|
2022-02-23 20:34:48 -08:00
|
|
|
|
|
|
|
// st_value of STT_TLS represents the assigned offset, not the actual
|
|
|
|
// address which is used by STT_FUNC and STT_OBJECT. STT_TLS symbols can
|
|
|
|
// only be referenced by special TLS relocations. It is usually an error if
|
|
|
|
// a STT_TLS symbol is replaced by a non-STT_TLS symbol, vice versa.
|
|
|
|
if (LLVM_UNLIKELY(sym.isTls()) && eSym.getType() != STT_TLS &&
|
|
|
|
eSym.getType() != STT_NOTYPE)
|
2024-11-06 22:33:51 -08:00
|
|
|
Err(ctx) << "TLS attribute mismatch: " << &sym << "\n>>> in " << sym.file
|
|
|
|
<< "\n>>> in " << this;
|
2022-02-23 20:34:48 -08:00
|
|
|
|
2022-03-15 19:24:41 -07:00
|
|
|
// Handle non-COMMON defined symbol below. !sym.file allows a symbol
|
|
|
|
// assignment to redefine a symbol without an error.
|
2024-12-07 20:46:02 -08:00
|
|
|
if (!sym.isDefined() || secIdx == SHN_UNDEF)
|
2022-02-22 10:07:58 -08:00
|
|
|
continue;
|
2024-12-01 14:18:09 -08:00
|
|
|
if (LLVM_UNLIKELY(secIdx >= SHN_LORESERVE)) {
|
|
|
|
if (secIdx == SHN_COMMON)
|
|
|
|
continue;
|
|
|
|
if (secIdx == SHN_XINDEX)
|
|
|
|
secIdx = check(getExtendedSymbolTableIndex<ELFT>(eSym, i, shndxTable));
|
|
|
|
else
|
|
|
|
secIdx = 0;
|
|
|
|
}
|
2022-03-15 19:24:41 -07:00
|
|
|
|
2025-01-25 17:29:28 -08:00
|
|
|
if (LLVM_UNLIKELY(secIdx >= sections.size())) {
|
|
|
|
Err(ctx) << this << ": invalid section index: " << secIdx;
|
|
|
|
continue;
|
|
|
|
}
|
2022-03-15 19:24:41 -07:00
|
|
|
InputSectionBase *sec = sections[secIdx];
|
|
|
|
if (sec == &InputSection::discarded) {
|
|
|
|
if (sym.traced) {
|
|
|
|
printTraceSymbol(Undefined{this, sym.getName(), sym.binding,
|
|
|
|
sym.stOther, sym.type, secIdx},
|
|
|
|
sym.getName());
|
|
|
|
}
|
|
|
|
if (sym.file == this) {
|
|
|
|
std::lock_guard<std::mutex> lock(mu);
|
2022-10-01 12:06:33 -07:00
|
|
|
ctx.nonPrevailingSyms.emplace_back(&sym, secIdx);
|
2022-03-15 19:24:41 -07:00
|
|
|
}
|
2022-02-22 10:07:58 -08:00
|
|
|
continue;
|
2022-03-15 19:24:41 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (sym.file == this) {
|
|
|
|
cast<Defined>(sym).section = sec;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2022-10-21 09:43:25 -07:00
|
|
|
if (sym.binding == STB_WEAK || binding == STB_WEAK)
|
2022-02-22 10:07:58 -08:00
|
|
|
continue;
|
2022-03-15 19:24:41 -07:00
|
|
|
std::lock_guard<std::mutex> lock(mu);
|
2022-10-01 12:06:33 -07:00
|
|
|
ctx.duplicates.push_back({&sym, this, sec, eSym.st_value});
|
2022-02-22 10:07:58 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-07 09:28:17 -05:00
|
|
|
// The handling of tentative definitions (COMMON symbols) in archives is murky.
|
2021-02-18 14:24:56 -05:00
|
|
|
// A tentative definition will be promoted to a global definition if there are
|
|
|
|
// no non-tentative definitions to dominate it. When we hold a tentative
|
|
|
|
// definition to a symbol and are inspecting archive members for inclusion
|
|
|
|
// there are 2 ways we can proceed:
|
2020-12-07 09:28:17 -05:00
|
|
|
//
|
|
|
|
// 1) Consider the tentative definition a 'real' definition (ie promotion from
|
|
|
|
// tentative to real definition has already happened) and not inspect
|
|
|
|
// archive members for Global/Weak definitions to replace the tentative
|
|
|
|
// definition. An archive member would only be included if it satisfies some
|
|
|
|
// other undefined symbol. This is the behavior Gold uses.
|
|
|
|
//
|
|
|
|
// 2) Consider the tentative definition as still undefined (ie the promotion to
|
2021-02-18 14:24:56 -05:00
|
|
|
// a real definition happens only after all symbol resolution is done).
|
2021-07-14 10:18:30 -07:00
|
|
|
// The linker searches archive members for STB_GLOBAL definitions to
|
2020-12-07 09:28:17 -05:00
|
|
|
// replace the tentative definition with. This is the behavior used by
|
|
|
|
// GNU ld.
|
|
|
|
//
|
|
|
|
// The second behavior is inherited from SysVR4, which based it on the FORTRAN
|
2021-03-29 14:40:43 -04:00
|
|
|
// COMMON BLOCK model. This behavior is needed for proper initialization in old
|
2020-12-07 09:28:17 -05:00
|
|
|
// (pre F90) FORTRAN code that is packaged into an archive.
|
|
|
|
//
|
2021-02-18 14:24:56 -05:00
|
|
|
// The following functions search archive members for definitions to replace
|
|
|
|
// tentative definitions (implementing behavior 2).
|
2020-12-07 09:28:17 -05:00
|
|
|
static bool isBitcodeNonCommonDef(MemoryBufferRef mb, StringRef symName,
|
|
|
|
StringRef archiveName) {
|
|
|
|
IRSymtabFile symtabFile = check(readIRSymtab(mb));
|
|
|
|
for (const irsymtab::Reader::SymbolRef &sym :
|
|
|
|
symtabFile.TheReader.symbols()) {
|
|
|
|
if (sym.isGlobal() && sym.getName() == symName)
|
2021-07-14 10:18:30 -07:00
|
|
|
return !sym.isUndefined() && !sym.isWeak() && !sym.isCommon();
|
2020-12-07 09:28:17 -05:00
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class ELFT>
|
2024-10-11 20:15:02 -07:00
|
|
|
static bool isNonCommonDef(Ctx &ctx, ELFKind ekind, MemoryBufferRef mb,
|
|
|
|
StringRef symName, StringRef archiveName) {
|
2024-10-06 18:09:52 -07:00
|
|
|
ObjFile<ELFT> *obj = make<ObjFile<ELFT>>(ctx, ekind, mb, archiveName);
|
2022-10-02 21:10:28 -07:00
|
|
|
obj->init();
|
2020-12-07 09:28:17 -05:00
|
|
|
StringRef stringtable = obj->getStringTable();
|
|
|
|
|
|
|
|
for (auto sym : obj->template getGlobalELFSyms<ELFT>()) {
|
|
|
|
Expected<StringRef> name = sym.getName(stringtable);
|
|
|
|
if (name && name.get() == symName)
|
2021-07-14 10:18:30 -07:00
|
|
|
return sym.isDefined() && sym.getBinding() == STB_GLOBAL &&
|
|
|
|
!sym.isCommon();
|
2020-12-07 09:28:17 -05:00
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2024-10-11 21:10:05 -07:00
|
|
|
static bool isNonCommonDef(Ctx &ctx, MemoryBufferRef mb, StringRef symName,
|
2020-12-07 09:28:17 -05:00
|
|
|
StringRef archiveName) {
|
2024-11-14 23:04:18 -08:00
|
|
|
switch (getELFKind(ctx, mb, archiveName)) {
|
2020-12-07 09:28:17 -05:00
|
|
|
case ELF32LEKind:
|
2024-10-11 20:15:02 -07:00
|
|
|
return isNonCommonDef<ELF32LE>(ctx, ELF32LEKind, mb, symName, archiveName);
|
2020-12-07 09:28:17 -05:00
|
|
|
case ELF32BEKind:
|
2024-10-11 20:15:02 -07:00
|
|
|
return isNonCommonDef<ELF32BE>(ctx, ELF32BEKind, mb, symName, archiveName);
|
2020-12-07 09:28:17 -05:00
|
|
|
case ELF64LEKind:
|
2024-10-11 20:15:02 -07:00
|
|
|
return isNonCommonDef<ELF64LE>(ctx, ELF64LEKind, mb, symName, archiveName);
|
2020-12-07 09:28:17 -05:00
|
|
|
case ELF64BEKind:
|
2024-10-11 20:15:02 -07:00
|
|
|
return isNonCommonDef<ELF64BE>(ctx, ELF64BEKind, mb, symName, archiveName);
|
2020-12-07 09:28:17 -05:00
|
|
|
default:
|
|
|
|
llvm_unreachable("getELFKind");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-10-06 11:27:24 -07:00
|
|
|
SharedFile::SharedFile(Ctx &ctx, MemoryBufferRef m, StringRef defaultSoName)
|
2024-11-14 23:04:18 -08:00
|
|
|
: ELFFileBase(ctx, SharedKind, getELFKind(ctx, m, ""), m),
|
|
|
|
soName(defaultSoName), isNeeded(!ctx.arg.asNeeded) {}
|
2022-10-02 20:16:13 -07:00
|
|
|
|
2019-04-08 17:35:55 +00:00
|
|
|
// Parse the version definitions in the object file if present, and return a
|
|
|
|
// vector whose nth element contains a pointer to the Elf_Verdef for version
|
|
|
|
// identifier n. Version identifiers that are not definitions map to nullptr.
|
|
|
|
template <typename ELFT>
|
2021-12-14 21:11:45 -08:00
|
|
|
static SmallVector<const void *, 0>
|
|
|
|
parseVerdefs(const uint8_t *base, const typename ELFT::Shdr *sec) {
|
2019-04-08 17:35:55 +00:00
|
|
|
if (!sec)
|
|
|
|
return {};
|
|
|
|
|
|
|
|
// Build the Verdefs array by following the chain of Elf_Verdef objects
|
|
|
|
// from the start of the .gnu.version_d section.
|
2021-12-14 21:11:45 -08:00
|
|
|
SmallVector<const void *, 0> verdefs;
|
2019-04-08 17:35:55 +00:00
|
|
|
const uint8_t *verdef = base + sec->sh_offset;
|
2021-12-14 21:11:45 -08:00
|
|
|
for (unsigned i = 0, e = sec->sh_info; i != e; ++i) {
|
2019-04-08 17:35:55 +00:00
|
|
|
auto *curVerdef = reinterpret_cast<const typename ELFT::Verdef *>(verdef);
|
|
|
|
verdef += curVerdef->vd_next;
|
|
|
|
unsigned verdefIndex = curVerdef->vd_ndx;
|
2021-12-14 21:11:45 -08:00
|
|
|
if (verdefIndex >= verdefs.size())
|
|
|
|
verdefs.resize(verdefIndex + 1);
|
2019-04-08 17:35:55 +00:00
|
|
|
verdefs[verdefIndex] = curVerdef;
|
|
|
|
}
|
|
|
|
return verdefs;
|
2019-04-05 20:16:26 +00:00
|
|
|
}
|
2015-09-08 15:50:05 +00:00
|
|
|
|
2020-05-15 20:36:41 -07:00
|
|
|
// Parse SHT_GNU_verneed to properly set the name of a versioned undefined
|
|
|
|
// symbol. We detect fatal issues which would cause vulnerabilities, but do not
|
|
|
|
// implement sophisticated error checking like in llvm-readobj because the value
|
|
|
|
// of such diagnostics is low.
|
|
|
|
template <typename ELFT>
|
|
|
|
std::vector<uint32_t> SharedFile::parseVerneed(const ELFFile<ELFT> &obj,
|
|
|
|
const typename ELFT::Shdr *sec) {
|
|
|
|
if (!sec)
|
|
|
|
return {};
|
|
|
|
std::vector<uint32_t> verneeds;
|
2024-11-16 11:58:10 -08:00
|
|
|
ArrayRef<uint8_t> data = CHECK2(obj.getSectionContents(*sec), this);
|
2020-05-15 20:36:41 -07:00
|
|
|
const uint8_t *verneedBuf = data.begin();
|
|
|
|
for (unsigned i = 0; i != sec->sh_info; ++i) {
|
2025-01-26 16:13:51 -08:00
|
|
|
if (verneedBuf + sizeof(typename ELFT::Verneed) > data.end()) {
|
|
|
|
Err(ctx) << this << " has an invalid Verneed";
|
|
|
|
break;
|
|
|
|
}
|
2020-05-15 20:36:41 -07:00
|
|
|
auto *vn = reinterpret_cast<const typename ELFT::Verneed *>(verneedBuf);
|
|
|
|
const uint8_t *vernauxBuf = verneedBuf + vn->vn_aux;
|
|
|
|
for (unsigned j = 0; j != vn->vn_cnt; ++j) {
|
2025-01-26 16:13:51 -08:00
|
|
|
if (vernauxBuf + sizeof(typename ELFT::Vernaux) > data.end()) {
|
|
|
|
Err(ctx) << this << " has an invalid Vernaux";
|
|
|
|
break;
|
|
|
|
}
|
2020-05-15 20:36:41 -07:00
|
|
|
auto *aux = reinterpret_cast<const typename ELFT::Vernaux *>(vernauxBuf);
|
2025-01-26 16:13:51 -08:00
|
|
|
if (aux->vna_name >= this->stringTable.size()) {
|
|
|
|
Err(ctx) << this << " has a Vernaux with an invalid vna_name";
|
|
|
|
break;
|
|
|
|
}
|
2020-05-15 20:36:41 -07:00
|
|
|
uint16_t version = aux->vna_other & VERSYM_VERSION;
|
|
|
|
if (version >= verneeds.size())
|
|
|
|
verneeds.resize(version + 1);
|
|
|
|
verneeds[version] = aux->vna_name;
|
|
|
|
vernauxBuf += aux->vna_next;
|
|
|
|
}
|
|
|
|
verneedBuf += vn->vn_next;
|
|
|
|
}
|
|
|
|
return verneeds;
|
|
|
|
}
|
|
|
|
|
[AArch64][GCS][LLD] Introduce -zgcs-report-dynamic Command Line Option (#127787)
When GCS was introduced to LLD, the gcs-report option allowed for a user
to gain information relating to if their relocatable objects supported
the feature. For an executable or shared-library to support GCS, all
relocatable objects must declare that they support GCS.
The gcs-report checks were only done on relocatable object files,
however for a program to enable GCS, the executable and all shared
libraries that it loads must enable GCS. gcs-report-dynamic enables
checks to be performed on all shared objects loaded by LLD, and in cases
where GCS is not supported, a warning or error will be emitted.
It should be noted that only shared files directly passed to LLD are
checked for GCS support. Files that are noted in the `DT_NEEDED` tags
are assumed to have had their GCS support checked when they were
created.
The behaviour of the -zgcs-dynamic-report option matches that of GNU ld.
The behaviour is as follows unless the user explicitly sets the value:
* -zgcs-report=warning or -zgcs-report=error implies
-zgcs-report-dynamic=warning.
This approach avoids inheriting an error level if the user wishes to
continue building a module without rebuilding all the shared libraries.
The same approach was taken for the GNU ld linker, so behaviour is
identical across the toolchains.
This implementation matches the error message and command line interface
used within the GNU ld Linker. See here:
https://github.com/bminor/binutils-gdb/commit/724a8341f6491283cf90038260c83a454b7268ef
To support this option being introduced, two other changes are included
as part of this PR. The first converts the -zgcs-report option to
utilise an Enum, opposed to StringRef values. This enables easier
tracking of the value the user defines when inheriting the value for the
gas-report-dynamic option. The second is to parse the Dynamic Objects
program headers to locate the GNU Attribute flag that shows GCS is
supported. This is needed so, when using the gcs-report-dynamic option,
LLD can correctly determine if a dynamic object supports GCS.
---------
Co-authored-by: Fangrui Song <i@maskray.me>
2025-03-16 01:15:05 +00:00
|
|
|
// Parse PT_GNU_PROPERTY segments in DSO. The process is similar to
|
|
|
|
// readGnuProperty, but we don't have the InputSection information.
|
|
|
|
template <typename ELFT>
|
|
|
|
void SharedFile::parseGnuAndFeatures(const ELFFile<ELFT> &obj) {
|
|
|
|
if (ctx.arg.emachine != EM_AARCH64)
|
|
|
|
return;
|
|
|
|
const uint8_t *base = obj.base();
|
|
|
|
auto phdrs = CHECK2(obj.program_headers(), this);
|
|
|
|
for (auto phdr : phdrs) {
|
|
|
|
if (phdr.p_type != PT_GNU_PROPERTY)
|
|
|
|
continue;
|
|
|
|
typename ELFT::Note note(
|
|
|
|
*reinterpret_cast<const typename ELFT::Nhdr *>(base + phdr.p_offset));
|
|
|
|
if (note.getType() != NT_GNU_PROPERTY_TYPE_0 || note.getName() != "GNU")
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ArrayRef<uint8_t> desc = note.getDesc(phdr.p_align);
|
|
|
|
parseGnuPropertyNote<ELFT>(ctx, *this, GNU_PROPERTY_AARCH64_FEATURE_1_AND,
|
|
|
|
desc, base);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-04-08 17:35:55 +00:00
|
|
|
// We do not usually care about alignments of data in shared object
|
|
|
|
// files because the loader takes care of it. However, if we promote a
|
|
|
|
// DSO symbol to point to .bss due to copy relocation, we need to keep
|
|
|
|
// the original alignment requirements. We infer it in this function.
|
|
|
|
template <typename ELFT>
|
|
|
|
static uint64_t getAlignment(ArrayRef<typename ELFT::Shdr> sections,
|
|
|
|
const typename ELFT::Sym &sym) {
|
|
|
|
uint64_t ret = UINT64_MAX;
|
|
|
|
if (sym.st_value)
|
2023-01-28 12:41:19 -08:00
|
|
|
ret = 1ULL << llvm::countr_zero((uint64_t)sym.st_value);
|
2019-04-08 17:35:55 +00:00
|
|
|
if (0 < sym.st_shndx && sym.st_shndx < sections.size())
|
|
|
|
ret = std::min<uint64_t>(ret, sections[sym.st_shndx].sh_addralign);
|
|
|
|
return (ret > UINT32_MAX) ? 0 : ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Fully parse the shared object file.
|
|
|
|
//
|
|
|
|
// This function parses symbol versions. If a DSO has version information,
|
|
|
|
// the file has a ".gnu.version_d" section which contains symbol version
|
|
|
|
// definitions. Each symbol is associated to one version through a table in
|
|
|
|
// ".gnu.version" section. That table is a parallel array for the symbol
|
|
|
|
// table, and each table entry contains an index in ".gnu.version_d".
|
|
|
|
//
|
|
|
|
// The special index 0 is reserved for VERF_NDX_LOCAL and 1 is for
|
|
|
|
// VER_NDX_GLOBAL. There's no table entry for these special versions in
|
|
|
|
// ".gnu.version_d".
|
|
|
|
//
|
|
|
|
// The file format for symbol versioning is perhaps a bit more complicated
|
|
|
|
// than necessary, but you can easily understand the code if you wrap your
|
|
|
|
// head around the data structure described above.
|
|
|
|
template <class ELFT> void SharedFile::parse() {
|
|
|
|
using Elf_Dyn = typename ELFT::Dyn;
|
|
|
|
using Elf_Shdr = typename ELFT::Shdr;
|
|
|
|
using Elf_Sym = typename ELFT::Sym;
|
|
|
|
using Elf_Verdef = typename ELFT::Verdef;
|
|
|
|
using Elf_Versym = typename ELFT::Versym;
|
|
|
|
|
2019-04-05 01:31:40 +00:00
|
|
|
ArrayRef<Elf_Dyn> dynamicTags;
|
2019-04-05 20:16:26 +00:00
|
|
|
const ELFFile<ELFT> obj = this->getObj<ELFT>();
|
2021-12-24 17:10:38 -08:00
|
|
|
ArrayRef<Elf_Shdr> sections = getELFShdrs<ELFT>();
|
2017-04-13 00:23:32 +00:00
|
|
|
|
2019-04-08 17:35:55 +00:00
|
|
|
const Elf_Shdr *versymSec = nullptr;
|
|
|
|
const Elf_Shdr *verdefSec = nullptr;
|
2020-05-15 20:36:41 -07:00
|
|
|
const Elf_Shdr *verneedSec = nullptr;
|
2024-12-08 12:32:55 -08:00
|
|
|
symbols = std::make_unique<Symbol *[]>(numSymbols);
|
|
|
|
|
2017-04-13 00:23:32 +00:00
|
|
|
// Search for .dynsym, .dynamic, .symtab, .gnu.version and .gnu.version_d.
|
2016-11-03 12:21:00 +00:00
|
|
|
for (const Elf_Shdr &sec : sections) {
|
2015-11-03 14:13:40 +00:00
|
|
|
switch (sec.sh_type) {
|
|
|
|
default:
|
|
|
|
continue;
|
|
|
|
case SHT_DYNAMIC:
|
2019-04-05 01:31:40 +00:00
|
|
|
dynamicTags =
|
2024-11-16 11:58:10 -08:00
|
|
|
CHECK2(obj.template getSectionContentsAsArray<Elf_Dyn>(sec), this);
|
2015-11-03 14:13:40 +00:00
|
|
|
break;
|
2016-04-27 20:22:31 +00:00
|
|
|
case SHT_GNU_versym:
|
2019-04-08 17:35:55 +00:00
|
|
|
versymSec = &sec;
|
2016-04-27 20:22:31 +00:00
|
|
|
break;
|
|
|
|
case SHT_GNU_verdef:
|
2019-04-08 17:35:55 +00:00
|
|
|
verdefSec = &sec;
|
2016-04-27 20:22:31 +00:00
|
|
|
break;
|
2020-05-15 20:36:41 -07:00
|
|
|
case SHT_GNU_verneed:
|
|
|
|
verneedSec = &sec;
|
|
|
|
break;
|
2015-11-03 14:13:40 +00:00
|
|
|
}
|
2015-09-08 15:50:05 +00:00
|
|
|
}
|
|
|
|
|
2024-12-08 15:59:03 -08:00
|
|
|
if (versymSec && numSymbols == 0) {
|
2024-11-06 22:04:52 -08:00
|
|
|
ErrAlways(ctx) << "SHT_GNU_versym should be associated with symbol table";
|
2019-04-08 17:35:55 +00:00
|
|
|
return;
|
|
|
|
}
|
2016-11-02 10:16:25 +00:00
|
|
|
|
2019-07-16 05:50:45 +00:00
|
|
|
// Search for a DT_SONAME tag to initialize this->soName.
|
2019-04-05 01:31:40 +00:00
|
|
|
for (const Elf_Dyn &dyn : dynamicTags) {
|
[ELF] Support --{,no-}allow-shlib-undefined
Summary:
In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking
an executable. This patch implements a check to error on undefined
symbols in a shared object, if all of its DT_NEEDED entries are seen.
Our approach resembles the one used in gold, achieves a good balance to
be useful but not too smart (ld.bfd traces all DSOs and emulates the
behavior of a dynamic linker to catch more cases).
The error is issued based on the symbol table, different from undefined
reference errors issued for relocations. It is most effective when there
are DSOs that were not linked with -z defs (e.g. when static sanitizers
runtime is used).
gold has a comment that some system libraries on GNU/Linux may have
spurious undefined references and thus system libraries should be
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
story may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the
future.
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: joerg, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57385
llvm-svn: 352826
2019-02-01 02:25:05 +00:00
|
|
|
if (dyn.d_tag == DT_NEEDED) {
|
|
|
|
uint64_t val = dyn.getVal();
|
2025-01-26 16:13:51 -08:00
|
|
|
if (val >= this->stringTable.size()) {
|
|
|
|
Err(ctx) << this << ": invalid DT_NEEDED entry";
|
|
|
|
return;
|
|
|
|
}
|
[ELF] Support --{,no-}allow-shlib-undefined
Summary:
In ld.bfd/gold, --no-allow-shlib-undefined is the default when linking
an executable. This patch implements a check to error on undefined
symbols in a shared object, if all of its DT_NEEDED entries are seen.
Our approach resembles the one used in gold, achieves a good balance to
be useful but not too smart (ld.bfd traces all DSOs and emulates the
behavior of a dynamic linker to catch more cases).
The error is issued based on the symbol table, different from undefined
reference errors issued for relocations. It is most effective when there
are DSOs that were not linked with -z defs (e.g. when static sanitizers
runtime is used).
gold has a comment that some system libraries on GNU/Linux may have
spurious undefined references and thus system libraries should be
excluded (https://sourceware.org/bugzilla/show_bug.cgi?id=6811). The
story may have changed now but we make --allow-shlib-undefined the
default for now. Its interaction with -shared can be discussed in the
future.
Reviewers: ruiu, grimar, pcc, espindola
Reviewed By: ruiu
Subscribers: joerg, emaste, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D57385
llvm-svn: 352826
2019-02-01 02:25:05 +00:00
|
|
|
dtNeeded.push_back(this->stringTable.data() + val);
|
|
|
|
} else if (dyn.d_tag == DT_SONAME) {
|
2017-02-24 19:52:52 +00:00
|
|
|
uint64_t val = dyn.getVal();
|
2025-01-26 16:13:51 -08:00
|
|
|
if (val >= this->stringTable.size()) {
|
|
|
|
Err(ctx) << this << ": invalid DT_SONAME entry";
|
|
|
|
return;
|
|
|
|
}
|
2017-04-26 23:00:32 +00:00
|
|
|
soName = this->stringTable.data() + val;
|
2015-10-01 15:47:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-04-08 17:35:55 +00:00
|
|
|
// DSOs are uniquified not by filename but by soname.
|
2024-11-16 22:34:12 -08:00
|
|
|
StringSaver &ss = ctx.saver;
|
2022-01-16 21:19:01 -08:00
|
|
|
DenseMap<CachedHashStringRef, SharedFile *>::iterator it;
|
2019-04-08 17:35:55 +00:00
|
|
|
bool wasInserted;
|
2022-01-16 21:19:01 -08:00
|
|
|
std::tie(it, wasInserted) =
|
2024-09-23 10:33:43 -07:00
|
|
|
ctx.symtab->soNames.try_emplace(CachedHashStringRef(soName), this);
|
2019-04-08 17:35:55 +00:00
|
|
|
|
|
|
|
// If a DSO appears more than once on the command line with and without
|
|
|
|
// --as-needed, --no-as-needed takes precedence over --as-needed because a
|
|
|
|
// user can add an extra DSO with --no-as-needed to force it to be added to
|
|
|
|
// the dependency list.
|
|
|
|
it->second->isNeeded |= isNeeded;
|
|
|
|
if (!wasInserted)
|
|
|
|
return;
|
2018-03-26 19:57:38 +00:00
|
|
|
|
2022-10-01 12:06:33 -07:00
|
|
|
ctx.sharedFiles.push_back(this);
|
2016-04-27 20:22:31 +00:00
|
|
|
|
2019-04-08 17:35:55 +00:00
|
|
|
verdefs = parseVerdefs<ELFT>(obj.base(), verdefSec);
|
2020-05-15 20:36:41 -07:00
|
|
|
std::vector<uint32_t> verneeds = parseVerneed<ELFT>(obj, verneedSec);
|
[AArch64][GCS][LLD] Introduce -zgcs-report-dynamic Command Line Option (#127787)
When GCS was introduced to LLD, the gcs-report option allowed for a user
to gain information relating to if their relocatable objects supported
the feature. For an executable or shared-library to support GCS, all
relocatable objects must declare that they support GCS.
The gcs-report checks were only done on relocatable object files,
however for a program to enable GCS, the executable and all shared
libraries that it loads must enable GCS. gcs-report-dynamic enables
checks to be performed on all shared objects loaded by LLD, and in cases
where GCS is not supported, a warning or error will be emitted.
It should be noted that only shared files directly passed to LLD are
checked for GCS support. Files that are noted in the `DT_NEEDED` tags
are assumed to have had their GCS support checked when they were
created.
The behaviour of the -zgcs-dynamic-report option matches that of GNU ld.
The behaviour is as follows unless the user explicitly sets the value:
* -zgcs-report=warning or -zgcs-report=error implies
-zgcs-report-dynamic=warning.
This approach avoids inheriting an error level if the user wishes to
continue building a module without rebuilding all the shared libraries.
The same approach was taken for the GNU ld linker, so behaviour is
identical across the toolchains.
This implementation matches the error message and command line interface
used within the GNU ld Linker. See here:
https://github.com/bminor/binutils-gdb/commit/724a8341f6491283cf90038260c83a454b7268ef
To support this option being introduced, two other changes are included
as part of this PR. The first converts the -zgcs-report option to
utilise an Enum, opposed to StringRef values. This enables easier
tracking of the value the user defines when inheriting the value for the
gas-report-dynamic option. The second is to parse the Dynamic Objects
program headers to locate the GNU Attribute flag that shows GCS is
supported. This is needed so, when using the gcs-report-dynamic option,
LLD can correctly determine if a dynamic object supports GCS.
---------
Co-authored-by: Fangrui Song <i@maskray.me>
2025-03-16 01:15:05 +00:00
|
|
|
parseGnuAndFeatures<ELFT>(obj);
|
2016-04-27 20:22:31 +00:00
|
|
|
|
2019-04-08 17:35:55 +00:00
|
|
|
// Parse ".gnu.version" section which is a parallel array for the symbol
|
|
|
|
// table. If a given file doesn't have a ".gnu.version" section, we use
|
|
|
|
// VER_NDX_GLOBAL.
|
2024-12-08 15:59:03 -08:00
|
|
|
size_t size = numSymbols - firstGlobal;
|
2020-05-15 20:36:41 -07:00
|
|
|
std::vector<uint16_t> versyms(size, VER_NDX_GLOBAL);
|
2019-04-08 17:35:55 +00:00
|
|
|
if (versymSec) {
|
|
|
|
ArrayRef<Elf_Versym> versym =
|
2024-11-16 11:58:10 -08:00
|
|
|
CHECK2(obj.template getSectionContentsAsArray<Elf_Versym>(*versymSec),
|
|
|
|
this)
|
2019-04-08 17:35:55 +00:00
|
|
|
.slice(firstGlobal);
|
|
|
|
for (size_t i = 0; i < size; ++i)
|
|
|
|
versyms[i] = versym[i].vs_index;
|
2016-04-27 20:22:31 +00:00
|
|
|
}
|
|
|
|
|
2018-04-06 20:53:06 +00:00
|
|
|
// System libraries can have a lot of symbols with versions. Using a
|
|
|
|
// fixed buffer for computing the versions name (foo@ver) can save a
|
|
|
|
// lot of allocations.
|
|
|
|
SmallString<0> versionedNameBuffer;
|
|
|
|
|
2017-10-28 20:15:56 +00:00
|
|
|
// Add symbols to the symbol table.
|
2019-04-05 20:16:26 +00:00
|
|
|
ArrayRef<Elf_Sym> syms = this->getGlobalELFSyms<ELFT>();
|
2021-12-15 22:45:27 -08:00
|
|
|
for (size_t i = 0, e = syms.size(); i != e; ++i) {
|
2018-03-26 19:57:38 +00:00
|
|
|
const Elf_Sym &sym = syms[i];
|
2016-04-29 17:46:07 +00:00
|
|
|
|
2018-03-15 17:10:50 +00:00
|
|
|
// ELF spec requires that all local symbols precede weak or global
|
|
|
|
// symbols in each symbol table, and the index of first non-local symbol
|
|
|
|
// is stored to sh_info. If a local symbol appears after some non-local
|
|
|
|
// symbol, that's a violation of the spec.
|
2024-11-16 11:58:10 -08:00
|
|
|
StringRef name = CHECK2(sym.getName(stringTable), this);
|
2017-12-15 00:01:33 +00:00
|
|
|
if (sym.getBinding() == STB_LOCAL) {
|
2024-11-06 22:33:51 -08:00
|
|
|
Err(ctx) << this << ": invalid local symbol '" << name
|
|
|
|
<< "' in global part of symbol table";
|
2017-12-15 00:01:33 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2022-09-04 16:21:19 -07:00
|
|
|
const uint16_t ver = versyms[i], idx = ver & ~VERSYM_HIDDEN;
|
2018-10-03 23:53:11 +00:00
|
|
|
if (sym.isUndefined()) {
|
2020-05-15 20:36:41 -07:00
|
|
|
// For unversioned undefined symbols, VER_NDX_GLOBAL makes more sense but
|
|
|
|
// as of binutils 2.34, GNU ld produces VER_NDX_LOCAL.
|
2022-09-04 16:21:19 -07:00
|
|
|
if (ver != VER_NDX_LOCAL && ver != VER_NDX_GLOBAL) {
|
2020-05-15 20:36:41 -07:00
|
|
|
if (idx >= verneeds.size()) {
|
2024-11-24 12:13:01 -08:00
|
|
|
ErrAlways(ctx) << "corrupt input file: version need index " << idx
|
|
|
|
<< " for symbol " << name
|
2024-11-06 22:04:52 -08:00
|
|
|
<< " is out of bounds\n>>> defined in " << this;
|
2020-05-15 20:36:41 -07:00
|
|
|
continue;
|
|
|
|
}
|
2021-12-23 21:54:32 -08:00
|
|
|
StringRef verName = stringTable.data() + verneeds[idx];
|
2020-05-15 20:36:41 -07:00
|
|
|
versionedNameBuffer.clear();
|
2024-11-16 15:20:20 -08:00
|
|
|
name = ss.save((name + "@" + verName).toStringRef(versionedNameBuffer));
|
2020-05-15 20:36:41 -07:00
|
|
|
}
|
2024-09-23 10:33:43 -07:00
|
|
|
Symbol *s = ctx.symtab->addSymbol(
|
2019-05-16 02:14:00 +00:00
|
|
|
Undefined{this, name, sym.getBinding(), sym.st_other, sym.getType()});
|
2025-01-30 22:24:04 -08:00
|
|
|
s->isExported = true;
|
2024-03-29 23:36:50 -07:00
|
|
|
if (sym.getBinding() != STB_WEAK &&
|
2024-09-21 12:47:47 -07:00
|
|
|
ctx.arg.unresolvedSymbolsInShlib != UnresolvedPolicy::Ignore)
|
2021-05-06 20:45:29 +07:00
|
|
|
requiredSymbols.push_back(s);
|
2018-10-03 23:53:11 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2022-09-04 16:21:19 -07:00
|
|
|
if (ver == VER_NDX_LOCAL ||
|
|
|
|
(ver != VER_NDX_GLOBAL && idx >= verdefs.size())) {
|
|
|
|
// In GNU ld < 2.31 (before 3be08ea4728b56d35e136af4e6fd3086ade17764), the
|
|
|
|
// MIPS port puts _gp_disp symbol into DSO files and incorrectly assigns
|
|
|
|
// VER_NDX_LOCAL. Workaround this bug.
|
2024-09-21 12:47:47 -07:00
|
|
|
if (ctx.arg.emachine == EM_MIPS && name == "_gp_disp")
|
2022-09-04 16:21:19 -07:00
|
|
|
continue;
|
2024-11-24 12:13:01 -08:00
|
|
|
ErrAlways(ctx) << "corrupt input file: version definition index " << idx
|
|
|
|
<< " for symbol " << name
|
2024-11-06 22:04:52 -08:00
|
|
|
<< " is out of bounds\n>>> defined in " << this;
|
2018-03-23 22:48:17 +00:00
|
|
|
continue;
|
2022-09-04 16:21:19 -07:00
|
|
|
}
|
2018-02-07 10:02:49 +00:00
|
|
|
|
2019-05-16 02:14:00 +00:00
|
|
|
uint32_t alignment = getAlignment<ELFT>(sections, sym);
|
2022-09-04 16:21:19 -07:00
|
|
|
if (ver == idx) {
|
2024-09-23 10:33:43 -07:00
|
|
|
auto *s = ctx.symtab->addSymbol(
|
2022-02-05 20:43:51 -08:00
|
|
|
SharedSymbol{*this, name, sym.getBinding(), sym.st_other,
|
|
|
|
sym.getType(), sym.st_value, sym.st_size, alignment});
|
2024-01-22 10:09:35 -08:00
|
|
|
s->dsoDefined = true;
|
2022-02-05 20:43:51 -08:00
|
|
|
if (s->file == this)
|
2023-11-16 01:03:52 -08:00
|
|
|
s->versionId = ver;
|
2019-05-16 02:14:00 +00:00
|
|
|
}
|
2017-01-06 22:30:35 +00:00
|
|
|
|
|
|
|
// Also add the symbol with the versioned name to handle undefined symbols
|
|
|
|
// with explicit versions.
|
2022-09-04 16:21:19 -07:00
|
|
|
if (ver == VER_NDX_GLOBAL)
|
2018-03-26 19:57:38 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
StringRef verName =
|
2021-12-23 21:54:32 -08:00
|
|
|
stringTable.data() +
|
2019-04-08 17:35:55 +00:00
|
|
|
reinterpret_cast<const Elf_Verdef *>(verdefs[idx])->getAux()->vda_name;
|
2018-04-06 20:53:06 +00:00
|
|
|
versionedNameBuffer.clear();
|
|
|
|
name = (name + "@" + verName).toStringRef(versionedNameBuffer);
|
2024-09-23 10:33:43 -07:00
|
|
|
auto *s = ctx.symtab->addSymbol(
|
2024-11-16 15:20:20 -08:00
|
|
|
SharedSymbol{*this, ss.save(name), sym.getBinding(), sym.st_other,
|
2022-02-05 20:43:51 -08:00
|
|
|
sym.getType(), sym.st_value, sym.st_size, alignment});
|
2024-01-22 10:09:35 -08:00
|
|
|
s->dsoDefined = true;
|
2022-02-05 20:43:51 -08:00
|
|
|
if (s->file == this)
|
2023-11-16 01:03:52 -08:00
|
|
|
s->versionId = idx;
|
2015-09-08 15:50:05 +00:00
|
|
|
}
|
|
|
|
}
|
2015-09-03 20:03:54 +00:00
|
|
|
|
2017-04-14 02:55:06 +00:00
|
|
|
static ELFKind getBitcodeELFKind(const Triple &t) {
|
2016-08-03 20:25:29 +00:00
|
|
|
if (t.isLittleEndian())
|
|
|
|
return t.isArch64Bit() ? ELF64LEKind : ELF32LEKind;
|
|
|
|
return t.isArch64Bit() ? ELF64BEKind : ELF32BEKind;
|
2016-06-29 06:12:39 +00:00
|
|
|
}
|
|
|
|
|
2024-11-14 23:04:18 -08:00
|
|
|
static uint16_t getBitcodeMachineKind(Ctx &ctx, StringRef path,
|
|
|
|
const Triple &t) {
|
2016-08-03 20:25:29 +00:00
|
|
|
switch (t.getArch()) {
|
2016-07-07 02:46:30 +00:00
|
|
|
case Triple::aarch64:
|
2021-02-08 08:55:28 -08:00
|
|
|
case Triple::aarch64_be:
|
2016-07-07 02:46:30 +00:00
|
|
|
return EM_AARCH64;
|
2018-08-27 12:40:00 +00:00
|
|
|
case Triple::amdgcn:
|
|
|
|
case Triple::r600:
|
|
|
|
return EM_AMDGPU;
|
2016-07-07 02:46:30 +00:00
|
|
|
case Triple::arm:
|
2023-11-21 13:12:06 +08:00
|
|
|
case Triple::armeb:
|
2017-02-28 03:00:48 +00:00
|
|
|
case Triple::thumb:
|
2023-11-21 13:12:06 +08:00
|
|
|
case Triple::thumbeb:
|
2016-07-07 02:46:30 +00:00
|
|
|
return EM_ARM;
|
2017-06-15 02:27:50 +00:00
|
|
|
case Triple::avr:
|
|
|
|
return EM_AVR;
|
2021-09-07 20:46:37 -07:00
|
|
|
case Triple::hexagon:
|
|
|
|
return EM_HEXAGON;
|
2023-07-25 17:03:28 +08:00
|
|
|
case Triple::loongarch32:
|
|
|
|
case Triple::loongarch64:
|
|
|
|
return EM_LOONGARCH;
|
2016-07-07 02:46:30 +00:00
|
|
|
case Triple::mips:
|
|
|
|
case Triple::mipsel:
|
|
|
|
case Triple::mips64:
|
|
|
|
case Triple::mips64el:
|
|
|
|
return EM_MIPS;
|
2019-01-10 13:43:06 +00:00
|
|
|
case Triple::msp430:
|
|
|
|
return EM_MSP430;
|
2016-07-07 02:46:30 +00:00
|
|
|
case Triple::ppc:
|
2021-01-02 12:18:05 -06:00
|
|
|
case Triple::ppcle:
|
2016-07-07 02:46:30 +00:00
|
|
|
return EM_PPC;
|
|
|
|
case Triple::ppc64:
|
2018-09-20 00:26:49 +00:00
|
|
|
case Triple::ppc64le:
|
2016-07-07 02:46:30 +00:00
|
|
|
return EM_PPC64;
|
2019-07-03 02:13:11 +00:00
|
|
|
case Triple::riscv32:
|
|
|
|
case Triple::riscv64:
|
|
|
|
return EM_RISCV;
|
2023-11-17 16:16:20 -05:00
|
|
|
case Triple::sparcv9:
|
|
|
|
return EM_SPARCV9;
|
2024-02-13 11:29:21 +01:00
|
|
|
case Triple::systemz:
|
|
|
|
return EM_S390;
|
2016-07-07 02:46:30 +00:00
|
|
|
case Triple::x86:
|
2016-08-03 20:25:29 +00:00
|
|
|
return t.isOSIAMCU() ? EM_IAMCU : EM_386;
|
2016-07-07 02:46:30 +00:00
|
|
|
case Triple::x86_64:
|
|
|
|
return EM_X86_64;
|
|
|
|
default:
|
2024-11-06 22:04:52 -08:00
|
|
|
ErrAlways(ctx) << path
|
|
|
|
<< ": could not infer e_machine from bitcode target triple "
|
|
|
|
<< t.str();
|
2018-05-22 20:20:25 +00:00
|
|
|
return EM_NONE;
|
2016-06-29 06:12:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-13 11:54:30 -04:00
|
|
|
static uint8_t getOsAbi(const Triple &t) {
|
|
|
|
switch (t.getOS()) {
|
|
|
|
case Triple::AMDHSA:
|
|
|
|
return ELF::ELFOSABI_AMDGPU_HSA;
|
|
|
|
case Triple::AMDPAL:
|
|
|
|
return ELF::ELFOSABI_AMDGPU_PAL;
|
|
|
|
case Triple::Mesa3D:
|
|
|
|
return ELF::ELFOSABI_AMDGPU_MESA3D;
|
|
|
|
default:
|
|
|
|
return ELF::ELFOSABI_NONE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-10-06 00:31:51 -07:00
|
|
|
BitcodeFile::BitcodeFile(Ctx &ctx, MemoryBufferRef mb, StringRef archiveName,
|
2021-12-22 17:41:50 -08:00
|
|
|
uint64_t offsetInArchive, bool lazy)
|
2024-10-06 18:09:52 -07:00
|
|
|
: InputFile(ctx, BitcodeKind, mb) {
|
2021-12-14 20:55:32 -08:00
|
|
|
this->archiveName = archiveName;
|
2021-12-22 17:41:50 -08:00
|
|
|
this->lazy = lazy;
|
2017-04-14 02:55:06 +00:00
|
|
|
|
2018-05-16 21:04:08 +00:00
|
|
|
std::string path = mb.getBufferIdentifier().str();
|
2024-09-21 12:47:47 -07:00
|
|
|
if (ctx.arg.thinLTOIndexOnly)
|
2024-10-03 23:06:18 -07:00
|
|
|
path = replaceThinLTOSuffix(ctx, mb.getBufferIdentifier());
|
2018-05-17 18:27:12 +00:00
|
|
|
|
|
|
|
// ThinLTO assumes that all MemoryBufferRefs given to it have a unique
|
|
|
|
// name. If two archives define two members with the same name, this
|
|
|
|
// causes a collision which result in only one of the objects being taken
|
|
|
|
// into consideration at LTO time (which very likely causes undefined
|
|
|
|
// symbols later in the link stage). So we append file offset to make
|
|
|
|
// filename unique.
|
2024-11-16 22:34:12 -08:00
|
|
|
StringSaver &ss = ctx.saver;
|
2022-01-20 14:53:18 -05:00
|
|
|
StringRef name = archiveName.empty()
|
2024-11-16 15:20:20 -08:00
|
|
|
? ss.save(path)
|
|
|
|
: ss.save(archiveName + "(" + path::filename(path) +
|
|
|
|
" at " + utostr(offsetInArchive) + ")");
|
2019-05-16 05:23:25 +00:00
|
|
|
MemoryBufferRef mbref(mb.getBuffer(), name);
|
2018-05-17 18:27:12 +00:00
|
|
|
|
2024-11-16 11:58:10 -08:00
|
|
|
obj = CHECK2(lto::InputFile::create(mbref), this);
|
2017-04-14 02:55:06 +00:00
|
|
|
|
|
|
|
Triple t(obj->getTargetTriple());
|
|
|
|
ekind = getBitcodeELFKind(t);
|
2024-11-14 23:04:18 -08:00
|
|
|
emachine = getBitcodeMachineKind(ctx, mb.getBufferIdentifier(), t);
|
2020-10-13 11:54:30 -04:00
|
|
|
osabi = getOsAbi(t);
|
2016-06-29 06:12:39 +00:00
|
|
|
}
|
2016-02-12 20:54:57 +00:00
|
|
|
|
2016-09-29 00:40:08 +00:00
|
|
|
static uint8_t mapVisibility(GlobalValue::VisibilityTypes gvVisibility) {
|
|
|
|
switch (gvVisibility) {
|
2016-03-07 19:06:14 +00:00
|
|
|
case GlobalValue::DefaultVisibility:
|
|
|
|
return STV_DEFAULT;
|
2016-03-07 00:54:17 +00:00
|
|
|
case GlobalValue::HiddenVisibility:
|
|
|
|
return STV_HIDDEN;
|
|
|
|
case GlobalValue::ProtectedVisibility:
|
|
|
|
return STV_PROTECTED;
|
|
|
|
}
|
2016-03-12 08:31:34 +00:00
|
|
|
llvm_unreachable("unknown visibility");
|
2016-03-11 18:46:51 +00:00
|
|
|
}
|
|
|
|
|
2024-10-03 23:06:18 -07:00
|
|
|
static void createBitcodeSymbol(Ctx &ctx, Symbol *&sym,
|
|
|
|
const lto::InputFile::Symbol &objSym,
|
|
|
|
BitcodeFile &f) {
|
2019-05-16 02:14:00 +00:00
|
|
|
uint8_t binding = objSym.isWeak() ? STB_WEAK : STB_GLOBAL;
|
2016-09-29 00:40:08 +00:00
|
|
|
uint8_t type = objSym.isTLS() ? STT_TLS : STT_NOTYPE;
|
|
|
|
uint8_t visibility = mapVisibility(objSym.getVisibility());
|
[Coding style change] Rename variables so that they start with a lowercase letter
This patch is mechanically generated by clang-llvm-rename tool that I wrote
using Clang Refactoring Engine just for creating this patch. You can see the
source code of the tool at https://reviews.llvm.org/D64123. There's no manual
post-processing; you can generate the same patch by re-running the tool against
lld's code base.
Here is the main discussion thread to change the LLVM coding style:
https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html
In the discussion thread, I proposed we use lld as a testbed for variable
naming scheme change, and this patch does that.
I chose to rename variables so that they are in camelCase, just because that
is a minimal change to make variables to start with a lowercase letter.
Note to downstream patch maintainers: if you are maintaining a downstream lld
repo, just rebasing ahead of this commit would cause massive merge conflicts
because this patch essentially changes every line in the lld subdirectory. But
there's a remedy.
clang-llvm-rename tool is a batch tool, so you can rename variables in your
downstream repo with the tool. Given that, here is how to rebase your repo to
a commit after the mass renaming:
1. rebase to the commit just before the mass variable renaming,
2. apply the tool to your downstream repo to mass-rename variables locally, and
3. rebase again to the head.
Most changes made by the tool should be identical for a downstream repo and
for the head, so at the step 3, almost all changes should be merged and
disappear. I'd expect that there would be some lines that you need to merge by
hand, but that shouldn't be too many.
Differential Revision: https://reviews.llvm.org/D64121
llvm-svn: 365595
2019-07-10 05:00:37 +00:00
|
|
|
|
Re-apply "[NFCI][LTO][lld] Optimize away symbol copies within LTO global resolution in ELF" (#107792)
Fix the use-after-free bug and re-apply
https://github.com/llvm/llvm-project/pull/106193
* Without the fix, the string referenced by `objSym.Name` could be
destroyed even if string saver keeps a copy of the referenced string.
This caused use-after-free.
* The fix ([latest
commit](https://github.com/llvm/llvm-project/pull/107792/commits/9776ed44cfb26172480145aed8f59ba78a6fa2ea))
updates `objSym.Name` to reference (via `StringRef`) the string saver's
copy.
Test:
1. For `lld/test/ELF/lto/asmundef.ll`, its test failure is reproducible
with `-DLLVM_USE_SANITIZER=Address` and gone with the fix.
3. Run all tests by following
https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild#try-local-changes.
* Without the fix, `ELF/lto/asmundef.ll` aborted the multi-stage test at
`@@@BUILD_STEP stage2/asan_ubsan check@@@`, defined
[here](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh#L30)
* With the fix, the [multi-stage
test](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh)
pass stage2 {asan, ubsan, masan}. This is also the test used by
https://lab.llvm.org/buildbot/#/builders/169
**Original commit message**
`StringMap<T>` creates a [copy of the
string](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMapEntry.h#L55-L58)
for entry insertions and intentionally keep copies [since the
implementation optimizes string memory
usage](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMap.h#L124).
On the other hand, linker keeps copies of symbol names [1] in
`lld::elf::parseFiles` [2] before invoking `compileBitcodeFiles` [3].
This change proposes to optimize away string copies inside
[LTO::GlobalResolutions](https://github.com/llvm/llvm-project/blob/24e791b4164986a1ca7776e3ae0292ef20d20c47/llvm/include/llvm/LTO/LTO.h#L409),
which will make LTO indexing more memory efficient for ELF. There are
similar opportunities for other (COFF, wasm, MachO) formats.
The optimization takes place for lld (ELF) only. For the rest of use
cases (gold plugin, `llvm-lto2`, etc), LTO owns a string saver to keep
copies and use global resolution key for de-duplication.
Together with @kazutakahirata's work to make `ComputeCrossModuleImport`
more memory efficient, we see a ~20% peak memory usage reduction in a
binary where peak memory usage needs to go down. Thanks to the
optimization in
https://github.com/llvm/llvm-project/commit/329ba523ccbbe68a12434926c92fd9a86494d958,
the max (as opposed to the sum) of `ComputeCrossModuleImport` or
`GlobalResolution` shows up in peak memory usage.
* Regarding correctness, the set of
[resolved](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/lib/LTO/LTO.cpp#L739)
[per-module
symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L188-L191)
is a subset of
[llvm::lto::InputFile::Symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L120).
And bitcode symbol parsing saves symbol name when iterating
`obj->symbols` in `BitcodeFile::parse` already. This change updates
`BitcodeFile::parseLazy` to keep copies of per-module undefined symbols.
* Presumably the undefined symbols in a LTO unit (copied in this patch
in linker unique saver) is a small set compared with the set of symbols
in global-resolution (copied before this patch), making this a
worthwhile trade-off. Benchmarking this change alone shows measurable
memory savings across various benchmarks.
[1] ELF
https://github.com/llvm/llvm-project/blob/1cea5c2138bef3d8fec75508df6dbb858e6e3560/lld/ELF/InputFiles.cpp#L1748
[2]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2863
[3]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2995
2024-09-09 11:16:58 -07:00
|
|
|
if (!sym) {
|
|
|
|
// Symbols can be duplicated in bitcode files because of '#include' and
|
2024-09-15 16:20:58 -07:00
|
|
|
// linkonce_odr. Use uniqueSaver to save symbol names for de-duplication.
|
Re-apply "[NFCI][LTO][lld] Optimize away symbol copies within LTO global resolution in ELF" (#107792)
Fix the use-after-free bug and re-apply
https://github.com/llvm/llvm-project/pull/106193
* Without the fix, the string referenced by `objSym.Name` could be
destroyed even if string saver keeps a copy of the referenced string.
This caused use-after-free.
* The fix ([latest
commit](https://github.com/llvm/llvm-project/pull/107792/commits/9776ed44cfb26172480145aed8f59ba78a6fa2ea))
updates `objSym.Name` to reference (via `StringRef`) the string saver's
copy.
Test:
1. For `lld/test/ELF/lto/asmundef.ll`, its test failure is reproducible
with `-DLLVM_USE_SANITIZER=Address` and gone with the fix.
3. Run all tests by following
https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild#try-local-changes.
* Without the fix, `ELF/lto/asmundef.ll` aborted the multi-stage test at
`@@@BUILD_STEP stage2/asan_ubsan check@@@`, defined
[here](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh#L30)
* With the fix, the [multi-stage
test](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh)
pass stage2 {asan, ubsan, masan}. This is also the test used by
https://lab.llvm.org/buildbot/#/builders/169
**Original commit message**
`StringMap<T>` creates a [copy of the
string](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMapEntry.h#L55-L58)
for entry insertions and intentionally keep copies [since the
implementation optimizes string memory
usage](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMap.h#L124).
On the other hand, linker keeps copies of symbol names [1] in
`lld::elf::parseFiles` [2] before invoking `compileBitcodeFiles` [3].
This change proposes to optimize away string copies inside
[LTO::GlobalResolutions](https://github.com/llvm/llvm-project/blob/24e791b4164986a1ca7776e3ae0292ef20d20c47/llvm/include/llvm/LTO/LTO.h#L409),
which will make LTO indexing more memory efficient for ELF. There are
similar opportunities for other (COFF, wasm, MachO) formats.
The optimization takes place for lld (ELF) only. For the rest of use
cases (gold plugin, `llvm-lto2`, etc), LTO owns a string saver to keep
copies and use global resolution key for de-duplication.
Together with @kazutakahirata's work to make `ComputeCrossModuleImport`
more memory efficient, we see a ~20% peak memory usage reduction in a
binary where peak memory usage needs to go down. Thanks to the
optimization in
https://github.com/llvm/llvm-project/commit/329ba523ccbbe68a12434926c92fd9a86494d958,
the max (as opposed to the sum) of `ComputeCrossModuleImport` or
`GlobalResolution` shows up in peak memory usage.
* Regarding correctness, the set of
[resolved](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/lib/LTO/LTO.cpp#L739)
[per-module
symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L188-L191)
is a subset of
[llvm::lto::InputFile::Symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L120).
And bitcode symbol parsing saves symbol name when iterating
`obj->symbols` in `BitcodeFile::parse` already. This change updates
`BitcodeFile::parseLazy` to keep copies of per-module undefined symbols.
* Presumably the undefined symbols in a LTO unit (copied in this patch
in linker unique saver) is a small set compared with the set of symbols
in global-resolution (copied before this patch), making this a
worthwhile trade-off. Benchmarking this change alone shows measurable
memory savings across various benchmarks.
[1] ELF
https://github.com/llvm/llvm-project/blob/1cea5c2138bef3d8fec75508df6dbb858e6e3560/lld/ELF/InputFiles.cpp#L1748
[2]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2863
[3]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2995
2024-09-09 11:16:58 -07:00
|
|
|
// Update objSym.Name to reference (via StringRef) the string saver's copy;
|
|
|
|
// this way LTO can reference the same string saver's copy rather than
|
|
|
|
// keeping copies of its own.
|
2024-11-16 22:34:12 -08:00
|
|
|
objSym.Name = ctx.uniqueSaver.save(objSym.getName());
|
2024-09-23 10:33:43 -07:00
|
|
|
sym = ctx.symtab->insert(objSym.getName());
|
Re-apply "[NFCI][LTO][lld] Optimize away symbol copies within LTO global resolution in ELF" (#107792)
Fix the use-after-free bug and re-apply
https://github.com/llvm/llvm-project/pull/106193
* Without the fix, the string referenced by `objSym.Name` could be
destroyed even if string saver keeps a copy of the referenced string.
This caused use-after-free.
* The fix ([latest
commit](https://github.com/llvm/llvm-project/pull/107792/commits/9776ed44cfb26172480145aed8f59ba78a6fa2ea))
updates `objSym.Name` to reference (via `StringRef`) the string saver's
copy.
Test:
1. For `lld/test/ELF/lto/asmundef.ll`, its test failure is reproducible
with `-DLLVM_USE_SANITIZER=Address` and gone with the fix.
3. Run all tests by following
https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild#try-local-changes.
* Without the fix, `ELF/lto/asmundef.ll` aborted the multi-stage test at
`@@@BUILD_STEP stage2/asan_ubsan check@@@`, defined
[here](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh#L30)
* With the fix, the [multi-stage
test](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh)
pass stage2 {asan, ubsan, masan}. This is also the test used by
https://lab.llvm.org/buildbot/#/builders/169
**Original commit message**
`StringMap<T>` creates a [copy of the
string](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMapEntry.h#L55-L58)
for entry insertions and intentionally keep copies [since the
implementation optimizes string memory
usage](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMap.h#L124).
On the other hand, linker keeps copies of symbol names [1] in
`lld::elf::parseFiles` [2] before invoking `compileBitcodeFiles` [3].
This change proposes to optimize away string copies inside
[LTO::GlobalResolutions](https://github.com/llvm/llvm-project/blob/24e791b4164986a1ca7776e3ae0292ef20d20c47/llvm/include/llvm/LTO/LTO.h#L409),
which will make LTO indexing more memory efficient for ELF. There are
similar opportunities for other (COFF, wasm, MachO) formats.
The optimization takes place for lld (ELF) only. For the rest of use
cases (gold plugin, `llvm-lto2`, etc), LTO owns a string saver to keep
copies and use global resolution key for de-duplication.
Together with @kazutakahirata's work to make `ComputeCrossModuleImport`
more memory efficient, we see a ~20% peak memory usage reduction in a
binary where peak memory usage needs to go down. Thanks to the
optimization in
https://github.com/llvm/llvm-project/commit/329ba523ccbbe68a12434926c92fd9a86494d958,
the max (as opposed to the sum) of `ComputeCrossModuleImport` or
`GlobalResolution` shows up in peak memory usage.
* Regarding correctness, the set of
[resolved](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/lib/LTO/LTO.cpp#L739)
[per-module
symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L188-L191)
is a subset of
[llvm::lto::InputFile::Symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L120).
And bitcode symbol parsing saves symbol name when iterating
`obj->symbols` in `BitcodeFile::parse` already. This change updates
`BitcodeFile::parseLazy` to keep copies of per-module undefined symbols.
* Presumably the undefined symbols in a LTO unit (copied in this patch
in linker unique saver) is a small set compared with the set of symbols
in global-resolution (copied before this patch), making this a
worthwhile trade-off. Benchmarking this change alone shows measurable
memory savings across various benchmarks.
[1] ELF
https://github.com/llvm/llvm-project/blob/1cea5c2138bef3d8fec75508df6dbb858e6e3560/lld/ELF/InputFiles.cpp#L1748
[2]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2863
[3]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2995
2024-09-09 11:16:58 -07:00
|
|
|
}
|
2021-12-30 12:03:29 -08:00
|
|
|
|
2024-12-11 08:55:05 -08:00
|
|
|
if (objSym.isUndefined()) {
|
2022-02-05 16:34:02 -08:00
|
|
|
Undefined newSym(&f, StringRef(), binding, visibility, type);
|
2024-10-11 23:34:43 -07:00
|
|
|
sym->resolve(ctx, newSym);
|
2021-12-30 12:03:29 -08:00
|
|
|
sym->referenced = true;
|
|
|
|
return;
|
2019-05-16 02:14:00 +00:00
|
|
|
}
|
2016-09-29 00:40:08 +00:00
|
|
|
|
2021-12-30 12:03:29 -08:00
|
|
|
if (objSym.isCommon()) {
|
2024-10-20 01:38:16 +00:00
|
|
|
sym->resolve(ctx, CommonSymbol{ctx, &f, StringRef(), binding, visibility,
|
2024-10-11 23:34:43 -07:00
|
|
|
STT_OBJECT, objSym.getCommonAlignment(),
|
|
|
|
objSym.getCommonSize()});
|
2021-12-30 12:03:29 -08:00
|
|
|
} else {
|
2024-10-20 01:38:16 +00:00
|
|
|
Defined newSym(ctx, &f, StringRef(), binding, visibility, type, 0, 0,
|
|
|
|
nullptr);
|
2024-12-08 09:33:48 -08:00
|
|
|
// The definition can be omitted if all bitcode definitions satisfy
|
|
|
|
// `canBeOmittedFromSymbolTable()` and isUsedInRegularObj is false.
|
2025-01-30 22:24:04 -08:00
|
|
|
// The latter condition is tested in parseVersionAndComputeIsPreemptible.
|
2024-12-08 09:33:48 -08:00
|
|
|
sym->ltoCanOmit = objSym.canBeOmittedFromSymbolTable() &&
|
|
|
|
(!sym->isDefined() || sym->ltoCanOmit);
|
2024-10-11 23:34:43 -07:00
|
|
|
sym->resolve(ctx, newSym);
|
2021-12-30 12:03:29 -08:00
|
|
|
}
|
2016-03-11 16:11:47 +00:00
|
|
|
}
|
|
|
|
|
2022-08-09 21:46:28 -07:00
|
|
|
void BitcodeFile::parse() {
|
2021-07-20 13:22:00 -07:00
|
|
|
for (std::pair<StringRef, Comdat::SelectionKind> s : obj->getComdatTable()) {
|
2019-05-22 09:06:42 +00:00
|
|
|
keptComdats.push_back(
|
2021-07-20 13:22:00 -07:00
|
|
|
s.second == Comdat::NoDeduplicate ||
|
2024-09-23 10:33:43 -07:00
|
|
|
ctx.symtab->comdatGroups.try_emplace(CachedHashStringRef(s.first), this)
|
2021-07-20 13:22:00 -07:00
|
|
|
.second);
|
|
|
|
}
|
2016-10-25 12:02:31 +00:00
|
|
|
|
2022-11-21 09:02:04 +00:00
|
|
|
if (numSymbols == 0) {
|
|
|
|
numSymbols = obj->symbols().size();
|
|
|
|
symbols = std::make_unique<Symbol *[]>(numSymbols);
|
|
|
|
}
|
2022-02-27 05:37:08 +00:00
|
|
|
// Process defined symbols first. See the comment in
|
|
|
|
// ObjFile<ELFT>::initializeSymbols.
|
2022-08-09 21:52:08 -07:00
|
|
|
for (auto [i, irSym] : llvm::enumerate(obj->symbols()))
|
|
|
|
if (!irSym.isUndefined())
|
2024-12-11 08:55:05 -08:00
|
|
|
createBitcodeSymbol(ctx, symbols[i], irSym, *this);
|
2022-08-09 21:52:08 -07:00
|
|
|
for (auto [i, irSym] : llvm::enumerate(obj->symbols()))
|
|
|
|
if (irSym.isUndefined())
|
2024-12-11 08:55:05 -08:00
|
|
|
createBitcodeSymbol(ctx, symbols[i], irSym, *this);
|
[ELF] Implement Dependent Libraries Feature
This patch implements a limited form of autolinking primarily designed to allow
either the --dependent-library compiler option, or "comment lib" pragmas (
https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp?view=vs-2017) in
C/C++ e.g. #pragma comment(lib, "foo"), to cause an ELF linker to automatically
add the specified library to the link when processing the input file generated
by the compiler.
Currently this extension is unique to LLVM and LLD. However, care has been taken
to design this feature so that it could be supported by other ELF linkers.
The design goals were to provide:
- A simple linking model for developers to reason about.
- The ability to to override autolinking from the linker command line.
- Source code compatibility, where possible, with "comment lib" pragmas in other
environments (MSVC in particular).
Dependent library support is implemented differently for ELF platforms than on
the other platforms. Primarily this difference is that on ELF we pass the
dependent library specifiers directly to the linker without manipulating them.
This is in contrast to other platforms where they are mapped to a specific
linker option by the compiler. This difference is a result of the greater
variety of ELF linkers and the fact that ELF linkers tend to handle libraries in
a more complicated fashion than on other platforms. This forces us to defer
handling the specifiers to the linker.
In order to achieve a level of source code compatibility with other platforms
we have restricted this feature to work with libraries that meet the following
"reasonable" requirements:
1. There are no competing defined symbols in a given set of libraries, or
if they exist, the program owner doesn't care which is linked to their
program.
2. There may be circular dependencies between libraries.
The binary representation is a mergeable string section (SHF_MERGE,
SHF_STRINGS), called .deplibs, with custom type SHT_LLVM_DEPENDENT_LIBRARIES
(0x6fff4c04). The compiler forms this section by concatenating the arguments of
the "comment lib" pragmas and --dependent-library options in the order they are
encountered. Partial (-r, -Ur) links are handled by concatenating .deplibs
sections with the normal mergeable string section rules. As an example, #pragma
comment(lib, "foo") would result in:
.section ".deplibs","MS",@llvm_dependent_libraries,1
.asciz "foo"
For LTO, equivalent information to the contents of a the .deplibs section can be
retrieved by the LLD for bitcode input files.
LLD processes the dependent library specifiers in the following way:
1. Dependent libraries which are found from the specifiers in .deplibs sections
of relocatable object files are added when the linker decides to include that
file (which could itself be in a library) in the link. Dependent libraries
behave as if they were appended to the command line after all other options. As
a consequence the set of dependent libraries are searched last to resolve
symbols.
2. It is an error if a file cannot be found for a given specifier.
3. Any command line options in effect at the end of the command line parsing apply
to the dependent libraries, e.g. --whole-archive.
4. The linker tries to add a library or relocatable object file from each of the
strings in a .deplibs section by; first, handling the string as if it was
specified on the command line; second, by looking for the string in each of the
library search paths in turn; third, by looking for a lib<string>.a or
lib<string>.so (depending on the current mode of the linker) in each of the
library search paths.
5. A new command line option --no-dependent-libraries tells LLD to ignore the
dependent libraries.
Rationale for the above points:
1. Adding the dependent libraries last makes the process simple to understand
from a developers perspective. All linkers are able to implement this scheme.
2. Error-ing for libraries that are not found seems like better behavior than
failing the link during symbol resolution.
3. It seems useful for the user to be able to apply command line options which
will affect all of the dependent libraries. There is a potential problem of
surprise for developers, who might not realize that these options would apply
to these "invisible" input files; however, despite the potential for surprise,
this is easy for developers to reason about and gives developers the control
that they may require.
4. This algorithm takes into account all of the different ways that ELF linkers
find input files. The different search methods are tried by the linker in most
obvious to least obvious order.
5. I considered adding finer grained control over which dependent libraries were
ignored (e.g. MSVC has /nodefaultlib:<library>); however, I concluded that this
is not necessary: if finer control is required developers can fall back to using
the command line directly.
RFC thread: http://lists.llvm.org/pipermail/llvm-dev/2019-March/131004.html.
Differential Revision: https://reviews.llvm.org/D60274
llvm-svn: 360984
2019-05-17 03:44:15 +00:00
|
|
|
|
|
|
|
for (auto l : obj->getDependentLibraries())
|
2024-10-03 23:06:18 -07:00
|
|
|
addDependentLibrary(ctx, l, this);
|
2016-02-12 20:54:57 +00:00
|
|
|
}
|
|
|
|
|
2021-12-22 17:41:50 -08:00
|
|
|
void BitcodeFile::parseLazy() {
|
2022-11-21 09:02:04 +00:00
|
|
|
numSymbols = obj->symbols().size();
|
|
|
|
symbols = std::make_unique<Symbol *[]>(numSymbols);
|
Re-apply "[NFCI][LTO][lld] Optimize away symbol copies within LTO global resolution in ELF" (#107792)
Fix the use-after-free bug and re-apply
https://github.com/llvm/llvm-project/pull/106193
* Without the fix, the string referenced by `objSym.Name` could be
destroyed even if string saver keeps a copy of the referenced string.
This caused use-after-free.
* The fix ([latest
commit](https://github.com/llvm/llvm-project/pull/107792/commits/9776ed44cfb26172480145aed8f59ba78a6fa2ea))
updates `objSym.Name` to reference (via `StringRef`) the string saver's
copy.
Test:
1. For `lld/test/ELF/lto/asmundef.ll`, its test failure is reproducible
with `-DLLVM_USE_SANITIZER=Address` and gone with the fix.
3. Run all tests by following
https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild#try-local-changes.
* Without the fix, `ELF/lto/asmundef.ll` aborted the multi-stage test at
`@@@BUILD_STEP stage2/asan_ubsan check@@@`, defined
[here](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh#L30)
* With the fix, the [multi-stage
test](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh)
pass stage2 {asan, ubsan, masan}. This is also the test used by
https://lab.llvm.org/buildbot/#/builders/169
**Original commit message**
`StringMap<T>` creates a [copy of the
string](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMapEntry.h#L55-L58)
for entry insertions and intentionally keep copies [since the
implementation optimizes string memory
usage](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMap.h#L124).
On the other hand, linker keeps copies of symbol names [1] in
`lld::elf::parseFiles` [2] before invoking `compileBitcodeFiles` [3].
This change proposes to optimize away string copies inside
[LTO::GlobalResolutions](https://github.com/llvm/llvm-project/blob/24e791b4164986a1ca7776e3ae0292ef20d20c47/llvm/include/llvm/LTO/LTO.h#L409),
which will make LTO indexing more memory efficient for ELF. There are
similar opportunities for other (COFF, wasm, MachO) formats.
The optimization takes place for lld (ELF) only. For the rest of use
cases (gold plugin, `llvm-lto2`, etc), LTO owns a string saver to keep
copies and use global resolution key for de-duplication.
Together with @kazutakahirata's work to make `ComputeCrossModuleImport`
more memory efficient, we see a ~20% peak memory usage reduction in a
binary where peak memory usage needs to go down. Thanks to the
optimization in
https://github.com/llvm/llvm-project/commit/329ba523ccbbe68a12434926c92fd9a86494d958,
the max (as opposed to the sum) of `ComputeCrossModuleImport` or
`GlobalResolution` shows up in peak memory usage.
* Regarding correctness, the set of
[resolved](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/lib/LTO/LTO.cpp#L739)
[per-module
symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L188-L191)
is a subset of
[llvm::lto::InputFile::Symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L120).
And bitcode symbol parsing saves symbol name when iterating
`obj->symbols` in `BitcodeFile::parse` already. This change updates
`BitcodeFile::parseLazy` to keep copies of per-module undefined symbols.
* Presumably the undefined symbols in a LTO unit (copied in this patch
in linker unique saver) is a small set compared with the set of symbols
in global-resolution (copied before this patch), making this a
worthwhile trade-off. Benchmarking this change alone shows measurable
memory savings across various benchmarks.
[1] ELF
https://github.com/llvm/llvm-project/blob/1cea5c2138bef3d8fec75508df6dbb858e6e3560/lld/ELF/InputFiles.cpp#L1748
[2]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2863
[3]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2995
2024-09-09 11:16:58 -07:00
|
|
|
for (auto [i, irSym] : llvm::enumerate(obj->symbols())) {
|
|
|
|
// Symbols can be duplicated in bitcode files because of '#include' and
|
2024-09-15 16:20:58 -07:00
|
|
|
// linkonce_odr. Use uniqueSaver to save symbol names for de-duplication.
|
Re-apply "[NFCI][LTO][lld] Optimize away symbol copies within LTO global resolution in ELF" (#107792)
Fix the use-after-free bug and re-apply
https://github.com/llvm/llvm-project/pull/106193
* Without the fix, the string referenced by `objSym.Name` could be
destroyed even if string saver keeps a copy of the referenced string.
This caused use-after-free.
* The fix ([latest
commit](https://github.com/llvm/llvm-project/pull/107792/commits/9776ed44cfb26172480145aed8f59ba78a6fa2ea))
updates `objSym.Name` to reference (via `StringRef`) the string saver's
copy.
Test:
1. For `lld/test/ELF/lto/asmundef.ll`, its test failure is reproducible
with `-DLLVM_USE_SANITIZER=Address` and gone with the fix.
3. Run all tests by following
https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild#try-local-changes.
* Without the fix, `ELF/lto/asmundef.ll` aborted the multi-stage test at
`@@@BUILD_STEP stage2/asan_ubsan check@@@`, defined
[here](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh#L30)
* With the fix, the [multi-stage
test](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh)
pass stage2 {asan, ubsan, masan}. This is also the test used by
https://lab.llvm.org/buildbot/#/builders/169
**Original commit message**
`StringMap<T>` creates a [copy of the
string](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMapEntry.h#L55-L58)
for entry insertions and intentionally keep copies [since the
implementation optimizes string memory
usage](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMap.h#L124).
On the other hand, linker keeps copies of symbol names [1] in
`lld::elf::parseFiles` [2] before invoking `compileBitcodeFiles` [3].
This change proposes to optimize away string copies inside
[LTO::GlobalResolutions](https://github.com/llvm/llvm-project/blob/24e791b4164986a1ca7776e3ae0292ef20d20c47/llvm/include/llvm/LTO/LTO.h#L409),
which will make LTO indexing more memory efficient for ELF. There are
similar opportunities for other (COFF, wasm, MachO) formats.
The optimization takes place for lld (ELF) only. For the rest of use
cases (gold plugin, `llvm-lto2`, etc), LTO owns a string saver to keep
copies and use global resolution key for de-duplication.
Together with @kazutakahirata's work to make `ComputeCrossModuleImport`
more memory efficient, we see a ~20% peak memory usage reduction in a
binary where peak memory usage needs to go down. Thanks to the
optimization in
https://github.com/llvm/llvm-project/commit/329ba523ccbbe68a12434926c92fd9a86494d958,
the max (as opposed to the sum) of `ComputeCrossModuleImport` or
`GlobalResolution` shows up in peak memory usage.
* Regarding correctness, the set of
[resolved](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/lib/LTO/LTO.cpp#L739)
[per-module
symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L188-L191)
is a subset of
[llvm::lto::InputFile::Symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L120).
And bitcode symbol parsing saves symbol name when iterating
`obj->symbols` in `BitcodeFile::parse` already. This change updates
`BitcodeFile::parseLazy` to keep copies of per-module undefined symbols.
* Presumably the undefined symbols in a LTO unit (copied in this patch
in linker unique saver) is a small set compared with the set of symbols
in global-resolution (copied before this patch), making this a
worthwhile trade-off. Benchmarking this change alone shows measurable
memory savings across various benchmarks.
[1] ELF
https://github.com/llvm/llvm-project/blob/1cea5c2138bef3d8fec75508df6dbb858e6e3560/lld/ELF/InputFiles.cpp#L1748
[2]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2863
[3]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2995
2024-09-09 11:16:58 -07:00
|
|
|
// Update objSym.Name to reference (via StringRef) the string saver's copy;
|
|
|
|
// this way LTO can reference the same string saver's copy rather than
|
|
|
|
// keeping copies of its own.
|
2024-11-16 22:34:12 -08:00
|
|
|
irSym.Name = ctx.uniqueSaver.save(irSym.getName());
|
2022-08-09 21:52:08 -07:00
|
|
|
if (!irSym.isUndefined()) {
|
2024-09-23 10:33:43 -07:00
|
|
|
auto *sym = ctx.symtab->insert(irSym.getName());
|
2024-10-11 23:34:43 -07:00
|
|
|
sym->resolve(ctx, LazySymbol{*this});
|
2022-08-09 21:52:08 -07:00
|
|
|
symbols[i] = sym;
|
2022-02-05 16:34:02 -08:00
|
|
|
}
|
Re-apply "[NFCI][LTO][lld] Optimize away symbol copies within LTO global resolution in ELF" (#107792)
Fix the use-after-free bug and re-apply
https://github.com/llvm/llvm-project/pull/106193
* Without the fix, the string referenced by `objSym.Name` could be
destroyed even if string saver keeps a copy of the referenced string.
This caused use-after-free.
* The fix ([latest
commit](https://github.com/llvm/llvm-project/pull/107792/commits/9776ed44cfb26172480145aed8f59ba78a6fa2ea))
updates `objSym.Name` to reference (via `StringRef`) the string saver's
copy.
Test:
1. For `lld/test/ELF/lto/asmundef.ll`, its test failure is reproducible
with `-DLLVM_USE_SANITIZER=Address` and gone with the fix.
3. Run all tests by following
https://github.com/google/sanitizers/wiki/SanitizerBotReproduceBuild#try-local-changes.
* Without the fix, `ELF/lto/asmundef.ll` aborted the multi-stage test at
`@@@BUILD_STEP stage2/asan_ubsan check@@@`, defined
[here](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh#L30)
* With the fix, the [multi-stage
test](https://github.com/llvm/llvm-zorg/blob/main/zorg/buildbot/builders/sanitizers/buildbot_fast.sh)
pass stage2 {asan, ubsan, masan}. This is also the test used by
https://lab.llvm.org/buildbot/#/builders/169
**Original commit message**
`StringMap<T>` creates a [copy of the
string](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMapEntry.h#L55-L58)
for entry insertions and intentionally keep copies [since the
implementation optimizes string memory
usage](https://github.com/llvm/llvm-project/blob/d4c519e7b2ac21350ec08b23eda44bf4a2d3c974/llvm/include/llvm/ADT/StringMap.h#L124).
On the other hand, linker keeps copies of symbol names [1] in
`lld::elf::parseFiles` [2] before invoking `compileBitcodeFiles` [3].
This change proposes to optimize away string copies inside
[LTO::GlobalResolutions](https://github.com/llvm/llvm-project/blob/24e791b4164986a1ca7776e3ae0292ef20d20c47/llvm/include/llvm/LTO/LTO.h#L409),
which will make LTO indexing more memory efficient for ELF. There are
similar opportunities for other (COFF, wasm, MachO) formats.
The optimization takes place for lld (ELF) only. For the rest of use
cases (gold plugin, `llvm-lto2`, etc), LTO owns a string saver to keep
copies and use global resolution key for de-duplication.
Together with @kazutakahirata's work to make `ComputeCrossModuleImport`
more memory efficient, we see a ~20% peak memory usage reduction in a
binary where peak memory usage needs to go down. Thanks to the
optimization in
https://github.com/llvm/llvm-project/commit/329ba523ccbbe68a12434926c92fd9a86494d958,
the max (as opposed to the sum) of `ComputeCrossModuleImport` or
`GlobalResolution` shows up in peak memory usage.
* Regarding correctness, the set of
[resolved](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/lib/LTO/LTO.cpp#L739)
[per-module
symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L188-L191)
is a subset of
[llvm::lto::InputFile::Symbols](https://github.com/llvm/llvm-project/blob/80c47ad3aec9d7f22e1b1bdc88960a91b66f89f1/llvm/include/llvm/LTO/LTO.h#L120).
And bitcode symbol parsing saves symbol name when iterating
`obj->symbols` in `BitcodeFile::parse` already. This change updates
`BitcodeFile::parseLazy` to keep copies of per-module undefined symbols.
* Presumably the undefined symbols in a LTO unit (copied in this patch
in linker unique saver) is a small set compared with the set of symbols
in global-resolution (copied before this patch), making this a
worthwhile trade-off. Benchmarking this change alone shows measurable
memory savings across various benchmarks.
[1] ELF
https://github.com/llvm/llvm-project/blob/1cea5c2138bef3d8fec75508df6dbb858e6e3560/lld/ELF/InputFiles.cpp#L1748
[2]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2863
[3]
https://github.com/llvm/llvm-project/blob/ef7b18a53c0d186dcda1e322be6035407fdedb55/lld/ELF/Driver.cpp#L2995
2024-09-09 11:16:58 -07:00
|
|
|
}
|
2021-12-22 17:41:50 -08:00
|
|
|
}
|
|
|
|
|
2022-02-22 10:07:58 -08:00
|
|
|
void BitcodeFile::postParse() {
|
2022-08-09 21:52:08 -07:00
|
|
|
for (auto [i, irSym] : llvm::enumerate(obj->symbols())) {
|
|
|
|
const Symbol &sym = *symbols[i];
|
|
|
|
if (sym.file == this || !sym.isDefined() || irSym.isUndefined() ||
|
|
|
|
irSym.isCommon() || irSym.isWeak())
|
2022-02-22 10:07:58 -08:00
|
|
|
continue;
|
2022-08-09 21:52:08 -07:00
|
|
|
int c = irSym.getComdatIndex();
|
2022-02-22 10:07:58 -08:00
|
|
|
if (c != -1 && !keptComdats[c])
|
|
|
|
continue;
|
2024-10-06 17:05:43 -07:00
|
|
|
reportDuplicate(ctx, sym, this, nullptr, 0);
|
2022-02-22 10:07:58 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-12-23 17:21:39 +00:00
|
|
|
void BinaryFile::parse() {
|
2018-10-22 08:35:39 +00:00
|
|
|
ArrayRef<uint8_t> data = arrayRefFromStringRef(mb.getBuffer());
|
2024-11-23 14:22:24 -08:00
|
|
|
auto *section =
|
|
|
|
make<InputSection>(this, ".data", SHT_PROGBITS, SHF_ALLOC | SHF_WRITE,
|
|
|
|
/*addralign=*/8, /*entsize=*/0, data);
|
2016-10-27 17:45:40 +00:00
|
|
|
sections.push_back(section);
|
|
|
|
|
2017-04-27 04:01:36 +00:00
|
|
|
// For each input file foo that is embedded to a result as a binary
|
|
|
|
// blob, we define _binary_foo_{start,end,size} symbols, so that
|
|
|
|
// user programs can access blobs by name. Non-alphanumeric
|
|
|
|
// characters in a filename are replaced with underscore.
|
|
|
|
std::string s = "_binary_" + mb.getBufferIdentifier().str();
|
2023-01-26 20:28:58 -05:00
|
|
|
for (char &c : s)
|
|
|
|
if (!isAlnum(c))
|
|
|
|
c = '_';
|
[Coding style change] Rename variables so that they start with a lowercase letter
This patch is mechanically generated by clang-llvm-rename tool that I wrote
using Clang Refactoring Engine just for creating this patch. You can see the
source code of the tool at https://reviews.llvm.org/D64123. There's no manual
post-processing; you can generate the same patch by re-running the tool against
lld's code base.
Here is the main discussion thread to change the LLVM coding style:
https://lists.llvm.org/pipermail/llvm-dev/2019-February/130083.html
In the discussion thread, I proposed we use lld as a testbed for variable
naming scheme change, and this patch does that.
I chose to rename variables so that they are in camelCase, just because that
is a minimal change to make variables to start with a lowercase letter.
Note to downstream patch maintainers: if you are maintaining a downstream lld
repo, just rebasing ahead of this commit would cause massive merge conflicts
because this patch essentially changes every line in the lld subdirectory. But
there's a remedy.
clang-llvm-rename tool is a batch tool, so you can rename variables in your
downstream repo with the tool. Given that, here is how to rebase your repo to
a commit after the mass renaming:
1. rebase to the commit just before the mass variable renaming,
2. apply the tool to your downstream repo to mass-rename variables locally, and
3. rebase again to the head.
Most changes made by the tool should be identical for a downstream repo and
for the head, so at the step 3, almost all changes should be merged and
disappear. I'd expect that there would be some lines that you need to merge by
hand, but that shouldn't be too many.
Differential Revision: https://reviews.llvm.org/D64121
llvm-svn: 365595
2019-07-10 05:00:37 +00:00
|
|
|
|
2024-11-16 22:34:12 -08:00
|
|
|
llvm::StringSaver &ss = ctx.saver;
|
2024-10-11 23:34:43 -07:00
|
|
|
ctx.symtab->addAndCheckDuplicate(
|
2024-11-16 15:20:20 -08:00
|
|
|
ctx, Defined{ctx, this, ss.save(s + "_start"), STB_GLOBAL, STV_DEFAULT,
|
2024-10-20 01:38:16 +00:00
|
|
|
STT_OBJECT, 0, 0, section});
|
|
|
|
ctx.symtab->addAndCheckDuplicate(
|
2024-11-16 15:20:20 -08:00
|
|
|
ctx, Defined{ctx, this, ss.save(s + "_end"), STB_GLOBAL, STV_DEFAULT,
|
2024-10-11 23:34:43 -07:00
|
|
|
STT_OBJECT, data.size(), 0, section});
|
|
|
|
ctx.symtab->addAndCheckDuplicate(
|
2024-11-16 15:20:20 -08:00
|
|
|
ctx, Defined{ctx, this, ss.save(s + "_size"), STB_GLOBAL, STV_DEFAULT,
|
2024-10-11 23:34:43 -07:00
|
|
|
STT_OBJECT, data.size(), 0, nullptr});
|
2016-09-09 22:08:04 +00:00
|
|
|
}
|
|
|
|
|
2024-10-06 18:09:52 -07:00
|
|
|
InputFile *elf::createInternalFile(Ctx &ctx, StringRef name) {
|
2024-01-29 13:26:33 -08:00
|
|
|
auto *file =
|
2024-10-06 18:09:52 -07:00
|
|
|
make<InputFile>(ctx, InputFile::InternalKind, MemoryBufferRef("", name));
|
2024-01-29 13:26:33 -08:00
|
|
|
// References from an internal file do not lead to --warn-backrefs
|
|
|
|
// diagnostics.
|
|
|
|
file->groupId = 0;
|
|
|
|
return file;
|
2024-01-22 09:09:46 -08:00
|
|
|
}
|
|
|
|
|
2024-11-16 23:50:34 -08:00
|
|
|
std::unique_ptr<ELFFileBase> elf::createObjFile(Ctx &ctx, MemoryBufferRef mb,
|
|
|
|
StringRef archiveName,
|
|
|
|
bool lazy) {
|
|
|
|
std::unique_ptr<ELFFileBase> f;
|
2024-11-14 23:04:18 -08:00
|
|
|
switch (getELFKind(ctx, mb, archiveName)) {
|
2017-04-26 22:51:51 +00:00
|
|
|
case ELF32LEKind:
|
2024-11-16 23:50:34 -08:00
|
|
|
f = std::make_unique<ObjFile<ELF32LE>>(ctx, ELF32LEKind, mb, archiveName);
|
2022-07-22 01:26:11 -07:00
|
|
|
break;
|
2017-04-26 22:51:51 +00:00
|
|
|
case ELF32BEKind:
|
2024-11-16 23:50:34 -08:00
|
|
|
f = std::make_unique<ObjFile<ELF32BE>>(ctx, ELF32BEKind, mb, archiveName);
|
2022-07-22 01:26:11 -07:00
|
|
|
break;
|
2017-04-26 22:51:51 +00:00
|
|
|
case ELF64LEKind:
|
2024-11-16 23:50:34 -08:00
|
|
|
f = std::make_unique<ObjFile<ELF64LE>>(ctx, ELF64LEKind, mb, archiveName);
|
2022-07-22 01:26:11 -07:00
|
|
|
break;
|
2017-04-26 22:51:51 +00:00
|
|
|
case ELF64BEKind:
|
2024-11-16 23:50:34 -08:00
|
|
|
f = std::make_unique<ObjFile<ELF64BE>>(ctx, ELF64BEKind, mb, archiveName);
|
2022-07-22 01:26:11 -07:00
|
|
|
break;
|
2017-04-26 22:51:51 +00:00
|
|
|
default:
|
|
|
|
llvm_unreachable("getELFKind");
|
|
|
|
}
|
2022-10-02 21:10:28 -07:00
|
|
|
f->init();
|
2022-07-22 01:26:11 -07:00
|
|
|
f->lazy = lazy;
|
|
|
|
return f;
|
2017-05-04 14:54:48 +00:00
|
|
|
}
|
|
|
|
|
2021-12-22 17:41:50 -08:00
|
|
|
template <class ELFT> void ObjFile<ELFT>::parseLazy() {
|
2021-12-23 20:23:13 -08:00
|
|
|
const ArrayRef<typename ELFT::Sym> eSyms = this->getELFSyms<ELFT>();
|
2022-11-21 09:02:04 +00:00
|
|
|
numSymbols = eSyms.size();
|
|
|
|
symbols = std::make_unique<Symbol *[]>(numSymbols);
|
Speed up --start-lib and --end-lib.
--{start,end}-lib give files grouped by the options the archive file
semantics. That is, each object file between them acts as if it were
in an archive file whose sole member is the file.
Therefore, files between --{start,end}-lib are linked to the final
output only if they are needed to resolve some undefined symbols.
Previously, the feature was implemented this way:
1. We read a symbol table and insert defined symbols to the symbol
table as lazy symbols.
2. If an undefind symbol is resolved to a lazy symbol, that lazy
symbol instantiate ObjFile class for that symbol, which re-insert
all defined symbols to the symbol table.
So, if an ObjFile is instantiated, defined symbols are inserted to the
symbol table twice. Since inserting long symbol names is not cheap,
there's a room to optimize here.
This patch optimzies it. Now, LazyObjFile remembers symbol handles and
passed them over to a new ObjFile instance, so that the ObjFile
doesn't insert the same strings.
Here is a quick benchmark to link clang. "Original" is the original
lld with unmodified command line options. For "Case 1" and "Case 2", I
extracted all files from archive files and replace .a's in a command
line with .o's wrapped with --{start,end}-lib. I used the original lld
for Case 1" and use this patch for Case 2.
Original: 5.892
Case 1: 6.001 (+1.8%)
Case 2: 5.701 (-3.2%)
So, interestingly, --{start,end}-lib are now faster than the regular
linking scheme with archive files. That's perhaps not too surprising,
though, because for regular archive files, we look up the symbol table
with the same string twice.
Differential Revision: https://reviews.llvm.org/D62188
llvm-svn: 361473
2019-05-23 09:53:30 +00:00
|
|
|
|
2021-12-23 20:23:13 -08:00
|
|
|
// resolve() may trigger this->extract() if an existing symbol is an undefined
|
|
|
|
// symbol. If that happens, this function has served its purpose, and we can
|
|
|
|
// exit from the loop early.
|
2024-10-06 11:27:24 -07:00
|
|
|
auto *symtab = ctx.symtab.get();
|
2022-11-26 21:12:30 -08:00
|
|
|
for (size_t i = firstGlobal, end = eSyms.size(); i != end; ++i) {
|
|
|
|
if (eSyms[i].st_shndx == SHN_UNDEF)
|
|
|
|
continue;
|
2024-11-16 11:58:10 -08:00
|
|
|
symbols[i] = symtab->insert(CHECK2(eSyms[i].getName(stringTable), this));
|
2024-10-11 23:34:43 -07:00
|
|
|
symbols[i]->resolve(ctx, LazySymbol{*this});
|
2022-11-26 21:12:30 -08:00
|
|
|
if (!lazy)
|
|
|
|
break;
|
|
|
|
}
|
2016-04-07 19:24:51 +00:00
|
|
|
}
|
|
|
|
|
2023-11-16 20:24:14 -08:00
|
|
|
bool InputFile::shouldExtractForCommon(StringRef name) const {
|
2022-07-22 11:54:27 -07:00
|
|
|
if (isa<BitcodeFile>(this))
|
2020-12-07 09:28:17 -05:00
|
|
|
return isBitcodeNonCommonDef(mb, name, archiveName);
|
|
|
|
|
2024-10-11 21:10:05 -07:00
|
|
|
return isNonCommonDef(ctx, mb, name, archiveName);
|
2020-12-07 09:28:17 -05:00
|
|
|
}
|
|
|
|
|
2024-10-03 23:06:18 -07:00
|
|
|
std::string elf::replaceThinLTOSuffix(Ctx &ctx, StringRef path) {
|
2024-09-21 12:47:47 -07:00
|
|
|
auto [suffix, repl] = ctx.arg.thinLTOObjectSuffixReplace;
|
[ELF] -thinlto-object-suffix-replace=: don't error if the path does not end with old suffix
Summary:
For -thinlto-object-suffix-replace=old\;new, in
tools/gold/gold-plugin.cpp, the thinlto object filename is Path minus
optional old suffix.
static std::string getThinLTOObjectFileName(StringRef Path, StringRef OldSuffix,
StringRef NewSuffix) {
if (OldSuffix.empty() && NewSuffix.empty())
return Path;
StringRef NewPath = Path;
NewPath.consume_back(OldSuffix);
std::string NewNewPath = NewPath;
NewNewPath += NewSuffix;
return NewNewPath;
}
Currently lld will error that the path does not end with old suffix.
This patch makes lld accept such paths but only add new suffix if Path
ends with old suffix. This fixes a link error where bitcode members in
an archive are regular LTO objects without old suffix.
Acording to tejohnson, this will "enable supporting mix and match of
minimized ThinLTO bitcode files with normal ThinLTO bitcode files in a
single link (where we want to apply the suffix replacement to the
minimized files, and just ignore it for the normal ThinLTO files)."
Reviewers: ruiu, pcc, tejohnson, espindola
Reviewed By: tejohnson
Subscribers: emaste, inglorion, arichardson, eraman, steven_wu, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D51055
llvm-svn: 340364
2018-08-21 23:28:12 +00:00
|
|
|
if (path.consume_back(suffix))
|
|
|
|
return (path + repl).str();
|
2020-01-28 20:23:46 +01:00
|
|
|
return std::string(path);
|
2018-05-17 18:27:12 +00:00
|
|
|
}
|
|
|
|
|
2020-05-14 22:18:58 -07:00
|
|
|
template class elf::ObjFile<ELF32LE>;
|
|
|
|
template class elf::ObjFile<ELF32BE>;
|
|
|
|
template class elf::ObjFile<ELF64LE>;
|
|
|
|
template class elf::ObjFile<ELF64BE>;
|
2015-11-20 02:19:36 +00:00
|
|
|
|
2019-04-08 17:35:55 +00:00
|
|
|
template void SharedFile::parse<ELF32LE>();
|
|
|
|
template void SharedFile::parse<ELF32BE>();
|
|
|
|
template void SharedFile::parse<ELF64LE>();
|
|
|
|
template void SharedFile::parse<ELF64BE>();
|