Notation: dst is `t->getThunkTargetSym()->getVA()`
On AArch64, when `src-0x8000000-r_addend <= dst < src-0x8000000`, the condition
`target->inBranchRange(rel.type, src, rel.sym->getVA(rel.addend))` may
incorrectly consider a thunk reusable.
`rel.addend = -getPCBias(rel.type)` resets the addend to 0 for AArch64/PPC
and the zero addend is used by `rel.sym->getVA(rel.addend)` to check
out-of-range relocations.
See the test for a case this computation is wrong:
`error: a.o:(.text_high+0x4): relocation R_AARCH64_JUMP26 out of range: -134217732 is not in [-134217728, 134217727]`
I have seen a real world case with r_addend=19960.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D117734
D54759 introduced aarch64-combined-dynrel.s and
aarch64-combined-dynrel-ifunc.s . Unfortunately the requires line
at the top was AArch64 instead of aarch64 which means they were never
run. Update the tests to use aarch64 and fix to match current lld output.
Differential Revision: https://reviews.llvm.org/D117896
This patch writes the full -cc1 command into the resulting .OBJ, like MSVC does. This allows for external tools (Recode, Live++) to rebuild a source file without any external dependency but the .OBJ itself (other than the compiler) and without knowledge of the build system.
The LF_BUILDINFO record stores a full path to the compiler, the PWD (CWD at program startup), a relative or absolute path to the source, and the full CC1 command line. The stored command line is self-standing (does not depend on the environment). In the same way, MSVC doesn't exactly store the provided command-line, but an expanded version (a somehow equivalent of CC1) which is also self-standing.
For more information see PR36198 and D43002.
Differential Revision: https://reviews.llvm.org/D80833
This flag is the default, so in ld64 it is not implemented, but it can
be useful to negate previous -all_load arguments. Specifically if your
build system has some global linker flags, that you may want to negate
for specific links. We use something like this today to make sure some
C++ symbols are automatically discovered for all links, which passing
-all_load hides.
Differential Revision: https://reviews.llvm.org/D117629
Fix a regression after aabe901d57d6df4cd2786163359a7b2a7aae8c32 (`[ELF] Remove
one redundant computeBinding`): isLocal() does not indicate that the symbol is
originally local. For simplicity, just drop this optimization.
In ld.lld, when an ObjFile/BitcodeFile is read in --start-lib state, the file is
given archive semantics. --end-lib closes the previous --start-lib. A build
system can use this feature as an alternative to archives. This patch ports
the feature to lld-macho.
--start-lib and --end-lib are positional, unlike usual ld64 options.
I think the slight drawback does not matter as (a) reusing option names
make build systems convenient (b) `--start-lib a.o b.o --end-lib` conveys more
information than an alternative design: `-objlib a.o -objlib b.o` because
--start-lib makes it clear which objects are in the same conceptual archive.
This provides flexibility (c) `-objlib`/`-filelist` interaction may be weird.
Close https://github.com/llvm/llvm-project/issues/52931
Reviewed By: #lld-macho, Jez Ng, oontvoo
Differential Revision: https://reviews.llvm.org/D116913
When an archive with an empty index contains only bitcode files, it is
handled as a group of lazy (--start-lib) object files. If there is a
non-bitcode file, there will be a diagnostic a la GNU ld.
For some programs, the archive member extraction ratio is high (e.g. for chrome,
79% archive members are extracted according to --print-archive-stats=). Because
symbol interning is cached for ObjFile::parseLazy but not for ArchiveFile,
parsing an archive as a group of --start-lib object files may be faster.
If the linker speculatively creates section representations for archive members,
the archive index will not be used.
If we take the above view, the archive index is essentially useless. If a user
wants a fast build without using --start-lib, they may just build thin archives
without index (`ar rcS --thin`).
Therefore, I suggest that we no longer treat the code as a hack, instead as a
supported feature. I believe we will do this anyway if we add parallel symbol
interning (parallel symbol interning for lazy object files is simpler than that
for archives).
Ecosystem issues:
* parseLazy actually has nearly the same behavior as ArchiveFile::parse, but the symbol order may be different.
* users may get addicted to the behavior and build archives not working with GNU ld and gold. I think it is easy to rebuild archives to be compatible.
Reviewed By: ikudrin
Differential Revision: https://reviews.llvm.org/D117284
D46245 added support for this in llvm-libtool, but while lld-link can
also create .lib files from .def files it didn't support aliases.
I compared the Inputs/library.def test against the output from
llvm-libtool and it matches, except for the fact that lld-link reorders
functions for some reason.
I have also verified that this fixes a bug I was running into while
trying to compile .def files to .lib files in MinGW-w64 (using lld-link
instead of llvm-libtool).
Differential Revision: https://reviews.llvm.org/D113365
This simplifies the code a bit. While here,
* change the `multiple relocation sections` diagnostic from `fatal` to `error` and include the relocated section name.
* drop less useful name from `getRelocTarget`. Without -r/--emit-relocs we don't need to get SHT_REL/SHT_RELA names.
It's still uncertain but whether we want to have `deduplicate-literals` be the
default flag for LLD out of the box or not. If `deduplicate-literals` is the default
behavior, then we will need a way override it and not deduplicate. Luckily, we
have `no_deduplicate` to fill this gap. For now, I've set the default to be false
which aligns with the existing behavior. That can only always be changed after
discussions on D117250.
Reviewed By: #lld-macho, int3
Differential Revision: https://reviews.llvm.org/D117387
We already perform memory initialization and apply global relocations
during start. It makes sense to performs data relocations too. I think
the reason we were not doing this already is solely historical.
Differential Revision: https://reviews.llvm.org/D117412
Sorting dynamic relocations is a bottleneck. Simplifying the comparator improves
performance. Linking clang is 4~5% faster with --threads=8.
This change may shuffle R_MIPS_REL32 for Mips and is a NFC for non-Mips.
This extends D81784. Sections can be discarded when linking a
relocatable output. Before the patch, LLD did not update the content
of debug sections and only replaced the corresponding relocations with
R_*_NONE, which could break the debug information.
Differential Revision: https://reviews.llvm.org/D116946
db08df0570b6dfaf00d7b1b8555c1d2d4effb224 does not work because part.relrDyn is
a unique_ptr and `reset` destroys the object which may still be referenced.
This commit uses the D114180 approach. Also improve the test to check that there
is no R_X86_64_RELATIVE.
Fix https://github.com/llvm/llvm-project/issues/53073
In case of a relocation error, GNU ld's link map includes
the archive member extraction information but not output sections.
Our -Map and --why-extract= are currently no-op in case of an error.
This change makes the two options work.
Reviewed By: ikudrin, peter.smith
Differential Revision: https://reviews.llvm.org/D116838
to prepare for D116838, otherwise for linkerscript/discard-section-err.s,
there will be a null pointer dereference in `part.relrDyn->getParent()->size`
in `finalizeSynthetic(part.relrDyn.get())`.
Depends on D112160
This adds the new options `--call-graph-profile-sort` (default),
`--no-call-graph-profile-sort` and `--print-symbol-order=`. If call graph
profile sorting is enabled, reads `__LLVM,__cg_profile` sections from object
files and uses the resulting graph to put callees and callers close to each
other in the final binary via the C3 clustering heuristic.
Differential Revision: https://reviews.llvm.org/D112164
rG1bb0caf56168 changed the datalayout of f80 on Windows 32 bits. But it
missed the related use in the LLD tests. This patch will fix the
problem catched by buildbot.
After {D117069}, map-file.s seems flaky. It seems that the "Total Write
map file" section always exists, but the "Write map file" sub-section
may or may not be emitted. So we check for the former.
After {D115416}, the "Write map file" event no longer shows up
in the time trace. Each time trace profiler instance is thread-local,
but we had neglected to initialize a separate instance for the mapfile
worker thread.
Reviewed By: keith
Differential Revision: https://reviews.llvm.org/D117069
When `file->fetch(sym)` is replaced with a no-op, no test fails.
The new test catches the case.
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D116916
We only support both TLSDESC and TLS GD for x86 so this is an x86-specific
problem. If both are used, only one R_X86_64_TLSDESC is produced and TLS GD
accesses will incorrectly reference R_X86_64_TLSDESC. Fix this by introducing
SymbolAux::tlsDescIdx.
Reviewed By: ikudrin
Differential Revision: https://reviews.llvm.org/D116900
Previously compounding was all-or-nothing. Now, the
compounding attempts will iterate and yield the most
compounds that still result in a valid packet.
They are LLD-specific and by convention we enforce the double-dash form to avoid
collision with short options (e.g. weird `-c olor-diagnostics` interpretation in
GNU ld). They are rarely used and to the best of my investigation the undesired
single-dash forms are not used in the wild.
The last use of `REQUIRES: debug` was removed in 2013 in 72c5d3d7c in favor of
`REQUIRES: asserts`.
The last use of `REQUIRES: asserts` was removed in 2015 in 251b0e268 when the
old COFF linker was removed.
lld's test suite currently has no behavior difference with respect to
assertions or debug builds (and hasn't had it for 6 years). Let's keep it that
way :)
Differential Revision: https://reviews.llvm.org/D115941
This reverts commit 859ebca744e634dcc89a2294ffa41574f947bd62.
The change contained many unrelated changes and e.g. restored
unit test failes for the old lld port.
This reverts commit 640beb38e7710b939b3cfb3f4c54accc694b1d30.
That commit caused performance degradtion in Quicksilver test QS:sGPU and a functional test failure in (rocPRIM rocprim.device_segmented_radix_sort).
Reverting until we have a better solution to s_cselect_b64 codegen cleanup
Change-Id: Ibf8e397df94001f248fba609f072088a46abae08
Reviewed By: kzhuravl
Differential Revision: https://reviews.llvm.org/D115960
Change-Id: Id169459ce4dfffa857d5645a0af50b0063ce1105
The diagnostic is emitted for an unextracted lazy symbol but suppressed for an
undefined symbol. Suppressing the diagnostic for unextracted lazy symbol
probably makes more sense because (a) an unextracted lazy symbol is quite
similar to an undefined symbol and (b) an unextracted lazy symbol is different
from "no such symbol".
In https://reviews.llvm.org/D86905, we introduce an optimization, when lld emits LLVM bitcode,
we allow bitcode writer flush data to disk early when buffered data size is above some threshold.
But when `--plugin-opt=emit-llvm` and `-o /dev/null` are used,
lld will trigger assertion `BytesRead >= 0 && static_cast<size_t>(BytesRead) == BytesFromDisk`.
When we write output to /dev/null, BytesRead is zero, but at this program point BytesFromDisk is always non-zero.
Reviewed By: stephan.yichao.zhao, MaskRay
Differential Revision: https://reviews.llvm.org/D112297
LLVM core library supports demangling other mangled symbols other than itanium,
such as D and Rust. LLD should use those demanglers in order to output pretty
demangled symbols on error messages.
Reviewed By: MaskRay, #lld-macho
Differential Revision: https://reviews.llvm.org/D116279
This reverts commit e60d6dfd5acdc821d391ad5af2c706397bdfd36a.
clang-ppc64le-rhel buildbot failed (https://lab.llvm.org/buildbot#builders/57/builds/13424):
tools/lld/MachO/CMakeFiles/lldMachO.dir/Symbols.cpp.o: In function `lld::demangle(llvm::StringRef, bool)':
Symbols.cpp:(.text._ZN3lld8demangleEN4llvm9StringRefEb[_ZN3lld8demangleEN4llvm9StringRefEb]+0x90): undefined reference to `llvm::demangle(std::string const&)'
LLVM core library supports demangling other mangled symbols other than itanium,
such as D and Rust. LLD should use those demanglers in order to output pretty
demangled symbols on error messages.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D116279
References from thread-local variable sections are treated as offsets
relative to the start of the thread-local data memory area, which is
initialized via copying all the TLV data sections (which are all
contiguous). If later data sections require a greater alignment than
earlier ones, the offsets of data within those sections won't be
guaranteed to aligned unless we normalize alignments. We therefore use
the largest alignment for all TLV data sections.
Reviewed By: #lld-macho, int3
Differential Revision: https://reviews.llvm.org/D116263
"Process symbol versions" may take 2+% time.
"Redirect symbols" may take 0.6% time.
This change speeds up the two passes and makes `*sym.getVersionSuffix()
== '@'` in the `undefined reference` diagnostic cleaner.
Linking chrome (no debug info) and another large program is 1.5% faster.
For empty-ver2.s: the behavior now matches GNU ld, though I'd consider the input
invalid and the exact behavior does not matter.
