In practice, all the Windows ARMNT IR objects show the architecture type
Thumb, not ARM.
Most other switch cases for architecture in lld/COFF check for and treat
`arm` and `thumb` equally.
Normally, this shouldn't happen. It can happen in exceptional
circumstances, if the compiled output of a bitcode object file
references symbols that weren't listed as undefined in the bitcode
object file itself.
This can at least happen in the following cases:
- A custom SEH personality is set via asm()
- Compiler generated calls to builtin helper functions, such as
__chkstk, or __rt_sdiv on arm
Both of these produce undefined references to symbols after compiling to
a regular object file, that aren't visible on the level of the IR object
file.
This is only an issue if the referenced symbols are provided as LTO
objects themselves; loading regular object files after the LTO
compilation works fine.
Custom SEH personalities are rare, but one CRT startup file in mingw-w64
does this. The referenced pesonality function is usually provided via an
import library, but for WinStore targets, a local dummy reimplementation
in C is used, which can be an LTO object.
Generated calls to builtins is very common, but the builtins aren't
usually provided as LTO objects (compiler-rt's builtins explicitly pass
-fno-lto when building), and many of the builtins are provided as raw .S
assembly files, which don't get built as LTO objects anyway, even if
built with -flto.
If hitting this unusual, but possible, situation, error out cleanly with
a clear message rather than crashing.
This is necessary if the object file containing _tls_used is built with
-fdata-sections; if this symbol is present, lld is going to include
references to it in the PE header, in the TLS_TABLE data directory.
Therefore, treat the symbol as a GC root, i.e. retain it (and whatever
other symbols the section chunk references) when doing doing GC
(/opt:ref), if the symbol is present.
When reading the bitcode input, undefined weak symbols will show up as
undefined symbols - which fails the early pass of checking for missing
symbols in symtab.reportUnresolvable(), before doing the actual LTO
compilation.
Mark such symbols as deferUndefined (added in
3785a413feef896e8a022731cc6ed405d5ebe81b /
https://reviews.llvm.org/D89004 for the -wrap option), to let them pass
through this LTO precheck. After the LTO compilation, the weak undefined
symbols will point towards an absolute null symbol as default.
Such weak undefined symbols are used for the TLS init function in the
Itanium C++ ABI, for TLS variables that potentially need to run a
constructor, when accessed across translation units.
This fixes https://github.com/llvm/llvm-project/issues/64513.
Such pointers are often used by the core parts of mingw-w64, to locally
define a function that might have been referred to with dllimport.
(MSVC style linkers can automatically provide such pointers, if there
are undefined references to `__imp_<func>` left but a definition of
`<func>` is available - although this prints the warning LNK4217. GNU ld
doesn't do this, so in mingw-w64, such things are generally handled by
manually providing the relevant `__imp_` pointers.)
Make sure that a full LTO build, that does LTO of both the `__imp_`
pointer and the object file referencing it, successfully resolves such
symbols.
This solution admittedly probably reduces the effect of the LTO
compilation if there would happen to be `__imp_` prefixed symbols
included, in LTO objects, that aren't actually used. Such symbols are
mostly used in the base toolchain, not often in user code, and usually
only the relevant object files are linked in anyway.
This fixes https://github.com/llvm/llvm-project/issues/57982.
Edited lld/ELF/Options.td to cdsort as well
CDSort function reordering outperforms the existing default heuristic (
hfsort/C^3) in terms of the performance of generated binaries while
being (almost) as fast. Thus, the suggestion is to change the default.
The speedup is up to 1.5% perf for large front-end binaries, and can be
moderate/neutral for "small" benchmarks.
High-level **perf impact** on two selected binaries:
clang-10 binary (built with LTO+AutoFDO/CSSPGO): wins on top of C^3 in
[0.3%..0.8%]
rocksDB-8 binary (built with LTO+CSSPGO): wins on top of C^3 in
[0.8%..1.5%]
More detailed measurements on the clang binary is at
[here](https://reviews.llvm.org/D152834#4445042)
The undefined symbol message suggests the source line when line number
information is available (see https://reviews.llvm.org/D31481).
When the undefined symbol is from a global variable, we won't get the
line information.
```
extern int undef;
namespace ns {
int *var[] = {
&undef
};
// DW_TAG_variable(DW_AT_decl_file/DW_AT_decl_line) is available while
// line number information is unavailable.
}
ld.lld: error: undefined symbol: undef
>>> referenced by undef-debug2.cc
>>> undef-debug2.o:(ns::var)
```
This patch utilizes `getEnclosingSymbol` to locate `var` and find
DW_TAG_variable for `var`:
```
ld.lld: error: undefined symbol: undef
>>> referenced by undef-debug2.cc:3 (/tmp/c/undef-debug2.cc:3)
>>> undef-debug2.o:(ns::var)
```
For a DSO with all DT_NEEDED entries accounted for, if it contains an
undefined non-weak symbol that shares a name with a non-exported
definition (hidden visibility or localized by a version script), and
there is no DSO definition, we should also report an error. Because the
definition is not exported, it cannot resolve the DSO reference at
runtime.
GNU ld introduced this error-checking in [April
2003](https://sourceware.org/pipermail/binutils/2003-April/026568.html).
The feature is available for executable links but not for -shared, and
it is
orthogonal to --no-allow-shlib-undefined. We make the feature part of
--no-allow-shlib-undefined and work with -shared when
--no-allow-shlib-undefined is specified.
A subset of this error-checking is covered by commit
1981b1b6b92f7579a30c9ed32dbdf3bc749c1b40 for --gc-sections discarded
sections. This patch covers non-discarded sections as well.
Internally, I have identified 2 bugs (which would fail with
LD_BIND_NOW=1) covered by commit
1981b1b6b92f7579a30c9ed32dbdf3bc749c1b40
Boundaries between code chunks of different architecture are always
aligned. 0x1000 seems to be a constant, this does not seem to be
affected by any command line alignment argument.
For an output section with no input section, GNU ld eliminates the
output section when there are only symbol assignments (e.g.
`.foo : { symbol = 42; }`) but not for `.foo : { . += 42; }`
(`SHF_ALLOC|SHF_WRITE`).
We choose to retain such an output section with a symbol assignment
(unless unreferenced `PROVIDE`). We copy the previous section flag (see
https://reviews.llvm.org/D37736) to hopefully make the current PT_LOAD
segment extend to the current output section:
* decrease the number of PT_LOAD segments
* If a new PT_LOAD segment is introduced without a page-size
alignment as a separator, there may be a run-time crash.
However, this `flags` copying behavior is not suitable for
`.foo : { . += 42; }` when `flags` contains `SHF_EXECINSTR`. The
executable bit is surprising
(https://discourse.llvm.org/t/lld-output-section-flag-assignment-behavior/74359).
I think we should drop SHF_EXECINSTR when copying `flags`. The risk is a
code section followed by `.foo : { symbol = 42; }` will be broken, which
I believe is unrelated as such uses are almost always related to data
sections.
For data-command-only output sections (e.g. `.foo : { QUAD(42) }`), we
keep allowing copyable SHF_WRITE.
Some tests are updated to drop the SHF_EXECINSTR flag. GNU ld doesn't
set SHF_EXECINSTR as well, though it sets SHF_WRITE for some tests while
we don't.
On windows if you passed /lldltocache:D:\tmp to lld and you didn't have
D: mounted it fail to create the cache dir D:\tmp, but the error message
is pretty hard to understand:
```
c:\code\llvm\llvm-project\out\debug>bin\lld-link.exe /lldltocache:D:\tmp
hello.obj
LLVM ERROR: no such file or directory
PLEASE submit a bug report to
https://github.com/llvm/llvm-project/issues/ and include the crash
backtrace.
Exception Code: 0xC000001D
```
Which lead one of our users to report this as a crash. I have just added
a bit better message so it now says:
```
c:\code\llvm\llvm-project\out\debug>bin\lld-link.exe /lldltocache:D:\tmp
hello.obj
LLVM ERROR: Can't create cache directory: D:\tmp
PLEASE submit a bug report to
https://github.com/llvm/llvm-project/issues/ and include the crash
backtrace.
```
I am not sure this is a fatal error because it's not something that
really should be reported as a bug to LLVM. But at least this gives a
bit more visibility on what to change.
Back when the --icf= option was hooked up in the MinGW frontend in LLD,
in 2017, lld-link didn't support safe ICF, and mapping it to noicf was
suggested in review: https://reviews.llvm.org/D40019
In 2018, in ab038025a50c79a89edb5832b163e8c729ceb703,
lld-link did get support for handling address significance tables,
allowing the ICF to operate safely on more sections.
Later in 2021, lld-link did get support for a separate safe ICF mode in
5bdc5e7efda4100c4d11085c2da8f1fb932ccce4 /
https://reviews.llvm.org/D97436.
Hook this up for the MinGW frontend as well.
In emscripten we have a build mode (the default actually) where the
runtime never exits and therefore `__cxa_atexit` is a dummy/stub
function that does nothing. In this case we would like to be able
completely DCE any otherwise-unused global dtor functions.
Fixes: https://github.com/emscripten-core/emscripten/issues/19993
In mingw mode, all linker paths are passed explicitly to the linker
by the compiler driver. Don't try to implicitly add linker paths
from the LIB environment variable or by detecting an MSVC
installation directory.
If the /winsysroot command line parameter is explicitly passed to
lld-link while /lldmingw is specified, it could be considered reasonable
to actually include those paths. However, modifying the code to
handle only the /winsysroot case but not the other ones, when the
mingw mode has been enabled, seems like much more code complexity
for a mostly hypothetical case.
Add a test for this when case when using LIB. (The code paths for
trying to detect an MSVC installation aren't really regression tested.)
Also fix an issue in the existing test for "Check that when /winsysroot
is specified, %LIB% is ignored.", where the LIB variable pointed
to a nonexistent directory, so the test would pass even if /winsysroot
wouldn't be specified.
Reland this after https://github.com/llvm/llvm-project/pull/68077 and
https://github.com/llvm/llvm-project/pull/69781 - the compiler-rt test
that used -lldmingw in MSVC environments has been updated to use a more
specific option.
Differential Revision: https://reviews.llvm.org/D144084
The MinGW mode (enabled with the flag -lldmingw) does allow duplicate
weak symbols. A test in
compiler-rt/test/profile/Windows/coverage-weak-lld.cpp does currently
enable the -lldmingw flag in an MSVC context, in order to deal with
duplicate weak symbols.
Add a new, separate, lld specific flag for enabling this. In MinGW mode,
this is enabled by default, otherwise it is disabled.
This allows making the MinGW mode more restrictive in adding libpaths
from the surrounding environment; in MinGW mode, all libpaths are passed
explicitly by the compiler driver to the linker, which is attempted in
https://reviews.llvm.org/D144084.
Follow-up to #69295: In `Writer<ELFT>::run`, the symbol passes are
flexible:
they can be placed almost everywhere before `scanRelocations`, with a
constraint
that the `computeIsPreemptible` pass must be invoked for linker-defined
non-local symbols.
Merge copyLocalSymbols and demoteLocalSymbolsInDiscardedSections to
simplify
code:
* Demoting local symbols can be made unconditional, not constrainted to
/DISCARD/ uses due to performance concerns
* `includeInSymtab` can be made faster
* Make symbol passes close to each other
* Decrease data cache misses due to saving an iteration over local
symbols
There is no speedup, likely due to the unconditional `dr->section`
access in `demoteAndCopyLocalSymbols`.
`gc-sections-tls.s` no longer reports an error because the TLS symbol is
converted to an Undefined.
When an input section is matched by /DISCARD/ in a linker script, GNU ld
reports errors for relocations referencing symbols defined in the section:
`.aaa' referenced in section `.bbb' of a.o: defined in discarded section `.aaa' of a.o
Implement the error by demoting eligible symbols to `Undefined` and changing
STB_WEAK to STB_GLOBAL. As a side benefit, in relocatable links, relocations
referencing symbols defined relative to /DISCARD/ discarded sections no longer
set symbol/type to zeros.
It's arguable whether a weak reference to a discarded symbol should lead to
errors. GNU ld reports an error and our demoting approach reports an error as
well.
Close#58891
Co-authored-by: Bevin Hansson <bevin.hansson@ericsson.com>
V3 has been deprecated for a while as well, so it can safely be removed
like V2 was removed.
- [Clang] Set minimum code object version to 4
- [lld] Fix tests using code object v3
- Remove code object V3 from the AMDGPU backend, and delete or port v3
tests to v4.
- Update docs to make it clear V3 can no longer be emitted.
CDSort function reordering outperforms the existing default heuristic (
hfsort/C^3) in terms of the performance of generated binaries while
being (almost) as fast. Thus, the suggestion is to change the default.
The speedup is up to 1.5% perf for large front-end binaries, and can be
moderate/neutral for "small" benchmarks.
High-level **perf impact** on two selected binaries:
clang-10 binary (built with LTO+AutoFDO/CSSPGO): wins on top of C^3 in
[0.3%..0.8%]
rocksDB-8 binary (built with LTO+CSSPGO): wins on top of C^3 in
[0.8%..1.5%]
More detailed measurements on the clang binary is at
[here](https://reviews.llvm.org/D152834#4445042)
Integrating MTE globals on Android revealed a lot of cases where
libraries are built as both archives and DSOs, and they're linked into
fully static and dynamic executables respectively.
MTE globals doesn't work for fully static executables. They need a
dynamic loader to process the special R_AARCH64_RELATIVE relocation
semantics with the encoded offset. Fully static executables that had
out-of-bounds derived symbols (like 'int* foo_end = foo[16]') crash
under MTE globals w/ static executables. So, LLD in its current form
simply errors out when you try and compile a fully static executable
that has a single MTE global variable in it.
It seems like a much better idea to simply have LLD not do the special
work for MTE globals in fully static contexts, and to drop any
unnecessary metadata. This means that you can build archives with MTE
globals and link them into both fully-static and dynamic executables.
Treat this as an alias for the --shared option.
In practice in GNU ld, they aren't exact aliases but there are small
subtle differences in what happens and what doesn't, when they are set,
but those differences are probably not intended by users who might be
using the --dll option (which gets passed by -mdll in the compiler
driver), and the differences are within the area where small details
differ between LLD and GNU ld anyway.
Some large AVR programs (for devices without long jump) may exceed
128KiB, and lld should give explicit errors other than generate wrong
executables silently.
This adds support for generating Chrome-tracing .json profile traces in
the LLD COFF driver.
Also add the necessary time scopes, so that the profile trace shows in
great detail which tasks are executed.
As an example, this is what we see when linking a Unreal Engine
executable:
For each R_X86_64_(REX_)GOTPCRELX relocation, check that the offset to the symbol is representable with 2^32 signed offset. If not, add a GOT entry for it and set its expr to R_GOT_PC so that we emit the GOT load instead of the relaxed lea. Do this in finalizeAddressDependentContent() where we iteratively attempt this (e.g. RISCV uses this for relaxation, ARM uses this to insert thunks).
Decided not to do the opposite of inserting GOT entries initially and removing them when relaxable because removing GOT entries isn't simple.
One drawback of this approach is that if we see any GOTPCRELX relocation, we'll create an empty .got even if it's not required in the end.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157020
This can happen when manually emitting strings into .drectve sections
with `__attribute__((section(".drectve")))`, which is a way to emulate
`#pragma comment(linker, "...")` for mingw compilers, without requiring
building with -fms-extensions.
Normally, this doesn't generate any comdat, but if compiled with
-fsanitize=address, this section does get turned into a comdat section.
This fixes#67261. This issue can be seen as a regression; a change in
the "lli" tool in 17.x triggers this case, if compiled with ASAN
enabled, triggering this unsupported corner case in LLD. With this
change, LLD can handle it.
Fixes a crash in `-Wl,-emit-relocs` where the linker was not able to
write linker-synthetic absolute symbols to the symbol table.
This change adds a new symbol flag (`WASM_SYMBOL_ABS`), which means that
the symbol's offset is absolute and not relative to a given segment.
Such symbols include `__stack_low` and `__stack_low`.
Note that wasm object files never contains such symbols, only binaries
linked with `-Wl,-emit-relocs`.
Fixes: #67111
