https://maskray.me/blog/2022-01-16-archives-and-start-lib
For every definition in an extracted archive member, we intern the symbol twice,
once for the archive index entry, once for the .o symbol table after extraction.
This is inefficient.
Symbols in a --start-lib ObjFile/BitcodeFile are only interned once because the
result is cached in symbols[i].
Just handle an archive using the --start-lib code path. We can therefore remove
ArchiveFile and LazyArchive. For many projects, archive member extraction ratio
is high and it is a net performance win. Linking a Release build of clang is
1.01x as fast.
Note: --start-lib scans symbols in the same order that llvm-ar adds them to the
index, so in the common case the semantics should be identical. If the archive
symbol table was created in a different order, or is incomplete, this strategy
may have different semantics. Such cases are considered user error.
The `is neither ET_REL nor LLVM bitcode` error is changed to a warning.
Previously an archive may have such members without a diagnostic. Using a
warning prevents breakage.
* For some tests, the diagnostics get improved where we did not consider
the archive member name: `b.a:` => `b.a(b.o):`.
* `no-obj.s`: the link is now allowed, matching GNU ld
* `archive-no-index.s`: the `is neither ET_REL nor LLVM bitcode` diagnostic is
demoted to a warning.
* `incompatible.s`: even when an archive is unextracted, we may report an
"incompatible with" error.
---
I recently decreased sizeof(SymbolUnion) by 8 and decreased memory usage quite a
bit, so retaining `symbols` for un-extracted archive members should not cause a
memory usage problem.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D119074
These global TLS symbols are shared across all shared libraries and
therefor should not be assumed to be local to the current module.
Also add new error in the linker when TLS relocations are used against
undefined symbols. TLS relocations are offsets into the current modules
tls data segment, and don't make sense for undefined symbols which are
modeled as global imports.
Fixes: https://github.com/emscripten-core/emscripten/issues/13398
Differential Revision: https://reviews.llvm.org/D119630
By unsetting this property, we are now able to internalize more symbols
during LTO. I compared the output of `-save-temps` for both LLD and
ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is
concerned.
(Thanks @smeenai for working on an initial version of this diff!)
Fixes https://github.com/llvm/llvm-project/issues/50574.
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D119372
Makes lld-link work in a non-MSVC shell by autodetecting MSVC toolchain. Also
adds support for /winsysroot and a few other switches.
All this is done by refactoring to share code with clang-cl's existing support
for the same.
Differential Revision: https://reviews.llvm.org/D118070
... to use hyphens instead of underscores, making it consistent with
our other substitutions like %no-arg-lld and %lld-watchos.
Reviewed By: keith
Differential Revision: https://reviews.llvm.org/D119513
We have a mix of substituted lld (`%lld`) and hard-coded lld (`ld64.lld`) commands.
When testing with different versions of LLD, this would require going into every place
where lld is hard-coded and changing that. If we centralize it, this'll only require us
to modify it in only one place and will make it easy to run the same test suite. Plus,
this will make it be consistent with how we write other tests.
Reviewed By: #lld-macho, int3, oontvoo
Differential Revision: https://reviews.llvm.org/D119394
Having clarified that executing the SerializeToHsaco pass can
depend on a ROCm installation, switch from calling lld as a library to
using the copy of lld guaranteed to be included in a ROCm install.
This removes the workaround introduced in D119277
Reviewed By: whchung
Differential Revision: https://reviews.llvm.org/D119463
https://maskray.me/blog/2022-02-06-all-about-common-symbols#no-define-common
In GNU ld, -dc only affects -r links and causes COMMON symbols to be allocated.
--no-define-common is defined to make COMMON symbols undefined for -shared.
AIUI --no-define-common is a workaround around glibc 2.1 time and not really useful.
gold confuses --define-common with -d/FORCE_COMMON_ALLOCATION and implements
--define-common with -d semantics. Its --no-define-common is incompatible with
GNU ld.
In ld.lld, b2a23cf3c0 fixed the default -r
behavior for COMMON symbols but ported the incompatible gold
--[no-]define-common. To the best of my knowledge, no project uses -dp
--[no-]define-common. So just remove these options.
-d/-dc are used by the following projects:
* grub grub-core/genmod.sh.in uses -Wl,-r,-d (https://lists.gnu.org/archive/html/grub-devel/2022-02/msg00088.html)
* FreeBSD crunchgen uses -Wl,-dc (https://reviews.freebsd.org/D34215)
A no-op implementation works for them. Only when a program inspects relocatable
output by itself and does not recognize COMMON symbols, there may be a problem.
This is an extremely unlikely case.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D119108
This fixes the issue raised in https://reviews.llvm.org/D108850#3303452
Before C++17, the function object is evaluated in a unspecified order. In the following example: https://godbolt.org/z/8ao4vdsr7 the function object is either evaluated before or after the arguments, depending on the compiler. With MSVC and /std:c++14 the function object is evaluated after the arguments; with clang and gcc, it is evaluated before. With C++17, the function object is guaranteed to be evaluated before the arguments, see: https://riptutorial.com/cplusplus/example/19369/evaluation-order-of-function-arguments
In our case, the issue was that the `args` conversion to `ArrayRef` was evaluated before the lambda call `link`, which internally was calling `parseFlavor()`, which in turned modified `args`. We ended with an `ArrayRef` argument that reflected the previous contents of `args`.
Add coverage for `-flavor` which we didn't have before.
Differential Revision: https://reviews.llvm.org/D119278
This makes it easier to pinpoint the source of the problem.
TODO: Have more relocation error messages make use of this
functionality.
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D118798
to decrease sizeof(SymbolUnion) from 72 to 64 on ELF64 platforms.
Use a dummy `Undefined` to prevent null pointer dereference (though unused)
`*rel.sym` in InputSectionBase::relocateAlloc.
The relocation order may shuffle a bit, but otherwise there is no behavior
difference.
lld/ELF/OutputSections.cpp includes llvm/Config/config.h for
LLVM_ENABLE_ZLIB definition, but llvm/Config/config.h doesn't exist in
standalone build.
To fix this, this patch moves LLVM_ENABLE_ZLIB from config.h to
llvm-config.h and updates OutputSections.cpp to include llvm-config.h
instead of config.h
Reviewed By: MaskRay, mgorny
Differential Revision: https://reviews.llvm.org/D119058
Adds `-pagezero_size`. `-pagezero_size` commonly used for kernel development.
`-pagezero_size` changes the `__PAGEZERO` size, removing that segment if it is set to zero.
One of the four flags from {D118570}
Now with error messages and tests.
Differential Revision: https://reviews.llvm.org/D118724
SharedSymbol::SharedSymbol initializes verdefIndex and Symbol::replace
copies verdefIndex.
By move verdefIndex assignment outside of ctor, Symbol::replace can be changed
to not copy verdefIndex. This can be used to decrease work for for
ObjKind/BitcodeKind.
Currently `this->getName() == newSym.getName()`.
By keeping the old nameData/nameSize, newSym's nameData/nameSize will be
ignored. The call sites can avoid calling getName().
printTraceSymbol needs to take the symbol name since `other`'s name is empty.
* partition and isPreemptible are frequently used. Move it to the front
* move used beside isUsedInRegularObj. They are similar and accessed together in .symtab finalizing
* move auxIdx/dynsymIndex/verdefIndex to the end.
This decreases code size.
For -no-pie/-pie, when `__real_foo` is interposable in a shared object, `foo` is
exported. This rule does not match GNU ld and is unneeded because:
* the exported `foo` does not interpose `__real_foo` at run-time
* the similar `__wrap_foo` <-> `foo` relation does not have the rule
A STV_PROTECTED shared definition does not set exportDynamic of a defined
symbol. This is on the basis that a protected definition cannot be preempted so
the export is unnecessary. However, the condition is imperfect because we don't
know whether the shared object was built with a symbolic option. Since dropping
the condition simplifies code and matches GNU ld, let's do it.
There's a couple of motivations here:
* LLD 12 (which I was originally testing with) was adding an undefined
symbol to the symbol table if you attempted to wrap an unreferenced
lazy symbol, which would later break `--no-allow-shlib-undefined`. LLD
on main actually produces a weak undefined symbol, so this doesn't
break anyway, but it's cleaner to not have the weak undefined symbol
as well. The new behavior also matches bfd and gold.
* PROVIDE in a linker script referencing a wrapped symbol would think
that an otherwise-unreferenced lazy symbol which was wrapped was
actually referenced, and therefore proceed with the definition, which
goes against expectations. The new behavior also matches bfd and gold.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D118756
Xcode 13 comes with a mismatched platform in libcompiler_rt.dylib,
so this creates a linker error on mac catalyst.
Fix it by adding it to the skip list.
Reviewed By: MaskRay, #lld-macho, int3
Differential Revision: https://reviews.llvm.org/D117925
-fprofile-use=/-fprofile-sample-use= compiles may produce REL-format
.rel.llvm.call-graph-profile even if the prevailing format is RELA on AArch64.
Add R_AARCH64_NONE to getImplicitAddend to fix this linker error:
```
ld.lld: error: internal linker error: cannot read addend for relocation R_AARCH64_NONE
PLEASE submit a bug report to https://crbug.com and run tools/clang/scripts/process_crashreports.py (only works inside Google) which will upload a report and include the crash backtrace.
```
Earlier in LLD's evolution, I tried to create the illusion that
subsections were indistinguishable from "top-level" sections. Thus, even
though the subsections shared many common field values, I hid those
common values away in a private Shared struct (see D105305). More
recently, however, @gkm added a public `Section` struct in D113241 that
served as an explicit way to store values that are common to an entire
set of subsections (aka InputSections). Now that we have another "common
value" struct, `Shared` has been rendered redundant. All its fields can
be moved into `Section` instead, and the pointer to `Shared` can be replaced
with a pointer to `Section`.
This `Section` pointer also has the advantage of letting us inspect other
subsections easily, simplifying the implementation of {D118798}.
P.S. I do think that having both `Section` and `InputSection` makes for
a slightly confusing naming scheme. I considered renaming `InputSection`
to `Subsection`, but that would break the symmetry with `OutputSection`.
It would also make us deviate from LLD-ELF's naming scheme.
This change is perf-neutral on my 3.2 GHz 16-Core Intel Xeon W machine:
base diff difference (95% CI)
sys_time 1.258 ± 0.031 1.248 ± 0.023 [ -1.6% .. +0.1%]
user_time 3.659 ± 0.047 3.658 ± 0.041 [ -0.5% .. +0.4%]
wall_time 4.640 ± 0.085 4.625 ± 0.063 [ -1.0% .. +0.3%]
samples 49 61
There's also no stat sig change in RSS (as measured by `time -l`):
base diff difference (95% CI)
time 998038627.097 ± 13567305.958 1003327715.556 ± 15210451.236 [ -0.2% .. +1.2%]
samples 31 36
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D118797
Fangrui Song