R_AARCH64_FUNCINIT64 is a dynamic relocation type for relocating
word-sized data in the output file using the return value of
a function. An R_AARCH64_FUNCINIT64 shall be relocated as an
R_AARCH64_IRELATIVE with the target symbol address if the target
symbol is non-preemptible, and it shall be a usage error to relocate an
R_AARCH64_FUNCINIT64 with a preemptible or STT_GNU_IFUNC target symbol.
The initial use case for this relocation type shall be for emitting
global variable field initializers for structure protection. With
structure protection, the relocation value computation is tied to the
compiler implementation in such a way that it would not be reasonable to
define a relocation type for it (for example, it may involve computing
a hash using a compiler-determined algorithm), hence the need for the
computation to be implemented as code in the binary.
Part of the AArch64 psABI extension:
https://github.com/ARM-software/abi-aa/issues/340
Reviewers: smithp35, fmayer, MaskRay
Reviewed By: fmayer
Pull Request: https://github.com/llvm/llvm-project/pull/156564
My 2020 change that added versioned symbol recognition
(reviews.llvm.org/D80059) checks both VER_NDX_LOCAL and VER_NDX_GLOBAL,
though test coverage was missing. lld/test/ELF/dso-undef-extract-lazy.s
checks that the undefined symbol is indeed considered unversioned.
https://github.com/llvm/llvm-project/pull/140307 added support for
cstring hashes in the orderfile to layout cstrings in a specific order,
but only when `--deduplicate-strings` is used. This PR supports cstring
ordering when `--no-deduplicate-strings` is used.
1. Create `cStringPriorities`, separate from `priorities`, to hold only
priorities for cstring pieces. This allows us to lookup by hash
directly, instead of first converting to a string. It also fixes a
contrived bug where we want to order a symbol named `CSTR;12345` rather
than a cstring.
2. Rather than calling `buildCStringPriorities()` which always
constructs and returns a vector, we use `forEachStringPiece()` to
efficiently iterate over cstring pieces without creating a new vector if
no cstring is ordered.
3. Create `SymbolPriorityEntry::{get,set}Priority()` helper functions to
simplify code.
We already ensure that code for different architectures is always placed
in different pages in `assignAddresses`. We represent those ranges using
their first and last chunks. However, the RVAs of those chunks may not
be page-aligned, for example, due to extra padding for entry-thunk
offsets. Align the chunk RVAs to the page boundary so that the emitted
ranges correctly include the entire region.
This change affects an existing test that checks corner cases triggered
by merging a data section into a code section. We may now include such
data in the code range. This differs from MSVC’s behavior, but it should
not cause practical issues, and the new behavior is arguably more
correct.
Fixes#168119.
Ran into a use case where we had a MachO object file with a section
symbol which did not have a section associated with it segfaults during
linking. This patch aims to handle such cases gracefully and avoid the
linker from crashing.
---------
Co-authored-by: Ellis Hoag <ellis.sparky.hoag@gmail.com>
The really painful part of this PR was updating all the test files. I
had some help from Gemini GLI there
which did a pretty good job (got maybe 80% of the updates done).
Fixes: #151015
This is especially important for writing i32 values larger than 2gb
which need to be encoded as negative SLEB vales in the binary.
Without this change offsets over 2gb are wrongly encoded and cause
validation errors.
Fixes: https://github.com/emscripten-core/emscripten/issues/25706
We typically shouldn't get this, but when we do (e.g. in #139439) we
should error out gracefully instead of crashing.
Note that we are stricter than ld64 here; ld64 appears to be able to
handle section offsets that point outside literal sections if the end
result is a valid pointer to another section in the input object file.
Supporting this would probably be a pain given our current design, and
it seems like enough of an edge case that it's onot worth it.
This test seems to have taken the lit documentation at its word:
https://llvm.org/docs/CommandGuide/lit.html#substitutions
"%t temporary file name unique to the test"
%t is in fact the **path** of a file. As suggested by the line below
that describing %basename_t.
This test (I assume) assumed it was just the filename itself and so left
a layout of:
```
$ tree tools/lld/test/
tools/lld/test/
├── CMakeFiles
├── ELF
│ └── Output
│ ├── aarch64-build-attributes.s.tmp
│ │ ├── pauth-bti-gcs.s
│ │ └── pauth-bti-pac.s
│ ├── aarch64-build-attributes.s.tmp.merged.o
│ ├── aarch64-build-attributes.s.tmp1.o
│ ├── aarch64-build-attributes.s.tmp2.o
│ └── aarch64-build-attributes.s.tmp3.o
├── Unit
│ └── lit.site.cfg.py
├── cmake_install.cmake
└── lit.site.cfg.py
```
Note how the 2 .s files are in the temp dir but the .o files are not.
This is fine, it works, but it's going to cost someone time to unpick
when this test actually does fail.
To fix this, remove %t from all the temp file names so they are created
in the temp dir, which is cleaned before each run.
New layout:
```
$ tree tools/lld/test/
tools/lld/test/
├── CMakeFiles
├── ELF
│ └── Output
│ └── aarch64-build-attributes.s.tmp
│ ├── 1.o
│ ├── 2.o
│ ├── 3.o
│ ├── merged.o
│ ├── pauth-bti-gcs.s
│ └── pauth-bti-pac.s
├── Unit
│ └── lit.site.cfg.py
├── cmake_install.cmake
└── lit.site.cfg.py
```
If an instruction at the high end of the 32-bit address space branches
to one at the low end, then the branch can be within range for a B or BL
instruction, and doesn't need a veneer. `ARM::inBranchRange` was failing
to detect this because it calculated the offset as an int64_t, so that
the offset was a small value ± 2^32 instead of just the small value.
Fixes#165211.
This fixes [issue
162148](https://github.com/llvm/llvm-project/issues/162148).
Common symbols are intended to have only a single version of the data
present in the final executable. The MSVC linker is able to successfully
deduplicate these chunks. If you have an application with a large number
of translation units with a large block of common data (this is
possible, for example, with Fortran code), then failing to deduplicate
these chunks can make the data size so large that the resulting
executable fails to load.
The logic in this patch doesn't catch all of the potential cases for
deduplication, but it should catch the most common ones.
The ASAN bot failed on my previous fix for builds without
threading support:
https://lab.llvm.org/buildbot/#/builders/24/builds/13751
However that build does have threading enabled, so I do
not think my change is the cause. I think the cause is
what #157917 will address:
> The new PR moves to use madvise() instead of the ad-hoc page referencing code I wrote which should avoid SIGSEGVs if the buffer is deallocated.
While that is being reviewed, do not run this test
anywhere. Though the failure I saw was with ASAN, I
think it could happen anywhere.
Also expand the #ifdef to remove unused code in this configuration. As
suggested in
https://github.com/llvm/llvm-project/pull/147134#issuecomment-3328612158.
I have also:
* Expanded the error message to explain why it's not allowed.
* Added a test for the error.
* Marked the original test as unsupported when threads are disabled.
Fixes issues we have had on Armv8 with threading disabled where this
test would crash every so often.
This change will hopefully be superseded by #157917, but that has been
in review a long time and I want to make the bot stable again.
I could just disable the test, but I'd like lld to function properly in
general in the meantime too.
Co-authored-by: John Holdsworth <github@johnholdsworth.com>
For sret arguments on aarch64, the x8 register is used as input
parameter to functions, even though x8 normally isn't an input parameter
register.
When delayloading a DLL, the first call of a delayloaded function ends
up calling a helper which resolves the function. Therefore, any input
arguments to the actual function to be called need to be backed up and
restored - this also includes x8.
This matches how MS link.exe also changed its delayloading trampoline,
between MSVC 2019 16.7 and 16.8 (between link.exe 14.27.29110.0 and
14.28.29333.0).
This fixes running LLDB on aarch64 mingw, after
ec28b95b7491bc2fbb6ec66cdbfd939e71255c42 and
93d326038959fd87fb666a8bf97d774d0abb3591. Those commits make LLDB load
liblldb.dll with delayloading, and the first function to be called,
SBDebugger::InitializeWithErrorHandling(), returns an SBError, which in
the itanium C++ ABI is returned as an sret via a pointer in x8.
Most likely we do want to support R_WASM_FUNCTION_INDEX_I32 at some
point but this relocation types (along with many others) is not
currently supported by `InputChunk::generateRelocationCode`.
See #146923
Add the flag `--tail-merge-strings` to enable tail merging of cstrings.
For example, if we have strings `mystring\0` and `ring\0`, we could
place `mystring\0` at address `0x1000` and `ring\0` at address `0x1004`
and have them share the same underlying data.
It turns out that many ObjC method names can be tail merged. For
example, `error:` and `doFoo:error:`. On a large iOS binary, we saw
nearly a 15% size improvement in the `__TEXT__objc_methname` section and
negligible impact on link time.
```
$ bloaty --domain=vm merged.o.stripped -- base.o.stripped
VM SIZE
--------------
+95% +5.85Ki [__TEXT]
-2.4% -239Ki __TEXT,__cstring
-14.5% -710Ki __TEXT,__objc_methname
-1.0% -944Ki TOTAL
```
Tail merging for MachO was originally removed in
7c269db779.
The previous implementation used `StringTableBuilder`, but that was
removed in
4308f031cd
to ensure deduplicated strings are aligned correctly. This
implementation ensures that tail merged strings are also aligned
correctly.
Special thanks to nocchijiang for pointing this out in
https://github.com/llvm/llvm-project/pull/158720#issuecomment-3310416030.
Depends on https://github.com/llvm/llvm-project/pull/161253.
lld would fail with "error: relocation out of range" if the thunk was
laid out more than 128 MB away from __delayLoadHelper2.
This patch changes the call sequence to load the offset into a register
and call through that, allowing for 32-bit offsets.
Fixes#161812
The stack pointer should be global, not hidden / dso-local. Marking it
as global allows it to be exported from the main module and imported
into side modules.
EhInputSection currently uses scanSection path, getting ignored marker
relocations and undefined symbol diagnostics for free. This might change
in the future. Add test coverage.
The test name had a typo from
https://github.com/llvm/llvm-project/pull/140307. Fix it.
I realized cstring ordering is not supported when string deduplication
is turned off. We could easily call `buildCStringPriorities()` in
`CStringSection::finalizeContents()`, but I worry it might harm build
performance since it creates multiple vectors and searches though maps.
If users are not deduplicating strings, they probably won't care to
order them, but it would be good to support this.
This check is designed to avoid exporting mutable globals in the case
when mutable globals are not available. However, it was being applied in
all cases even when mutable globals was enabled.
This error is particularly bad since mutable-globals have been enabled
in default CPU for a while now, meaning that this condition should not
be firing in the wild very often.
9cc9efc483339ece1d52923569bb755db42b69f3 changed LLD to use a
StringTableBuilder for optimizing the string table, used for long
section and symbol names.
That commit had a bug, where the symbol table entry for an import thunk
with a long symbol name wouldn't get fetched from the
StringTableBuilder, if the base symbol name (without the "__imp_"
prefix) wasn't over 8 chars.
This should fix issues with Go, which errors out on reading the
executables with a broken symbol table, as noted in
https://github.com/mstorsjo/llvm-mingw/issues/518 and
https://github.com/golang/go/issues/75219.
Previously we only tested it as taking a pair of `module` and `name`,
e.g `--import-memory=mymodule,mymemory`.
However, rather confusingly, if you just specified `--import-memory=foo`
it would set the module to `foo` and the name to empty string.
This changes the interpretation of `--import-memory=foo` to mean import
`foo` from the default module (which is currently `env`, but one day we
make it configurable).
If ld.lld is invoked without the `-o` option, it defaults to writing its
output to `a.out` in the current directory. This can cause 'Permission
denied' errors if a test is executed in a directory without write
permissions, as can happen in some build environments.
Add `-o %t2` to this command, consistent with other commands in the same
test file, to prevent this failure by ensuring ld.lld writes to a
temporary file instead of `a.out`.
Add the `--{no-}separate-cstring-literal-sections` option to emit
cstring literals into sections defined by their section name. This
allows for changes like https://github.com/swiftlang/swift/pull/84300
and https://github.com/swiftlang/swift/pull/84236 to actually have an
affect. The default behavior has not changed.
The reason this is useful is because strings in different sections might
have different access patterns at runtime. By splitting these strings
into separate sections, we may reduce the number of page faults during
startup. For example, the ObjC runtime accesses all strings in
`__objc_classname` before main.
fixes#156417
When the relocation section is placed before the relocated section and
the relocated section is not defined in the linker script, an error will
occur during the linking process.
**Issue Cause:**
In a.ro, `.rela.text` precedes its relocated `InputSection` `.text`.
`addOrphanSections` doesn't handle this scenario.
When it processes `.rela.text`, in the called `getOutputSectionName`,
`rel->getOutputSection()` is nullptr (input `.text` doesn't yet have a
parent output section), leading to an assertion failure.
**Solution:**
For --emit-relocs and -r, ensure the output section for `.text.foo` is
created before the output section for `.rela.text.foo`.
---------
Co-authored-by: Fangrui Song <i@maskray.me>
Resolves#141712.
As described in the issue, this PR adds support for `/nodbgdirmerge`
flag in LLD to align with MS link. When the flag is specified, the
linker will emit the debug directory section in `.cvinfo` section,
instead of merging it to the `.rdata`. The flag will be ignored on
MinGW.
---------
Co-authored-by: namazso <admin@namazso.eu>
Rather then defining these tags in each object file that requires them
we can can declare them as undefined and require that they defined
externally in, for example, compiler-rt or libcxxabi.
Add `--print-gc-sections=<file>` to redirect garbage collection section
listing to a file, avoiding contamination of stdout with other linker
output. mold has recently added the option.
GNU ld feature request:
https://sourceware.org/bugzilla/show_bug.cgi?id=33331
Previously, `/summary` was meant to print some PDB information. Now move
handling of `/summary` to `Writer.cpp` so that it can have an effect
when `/debug` isn't provided. This will also provide grounds for
extending with more general information.
When a symbol is imported from a DLL, a base relocation record is
normally emitted.
However, if the import is pulled in via a wrapped symbol (using
`--wrap`) and later dropped because it is only referenced weakly, a
dangling base relocation remains in the output.
At runtime, this relocation changes the symbol value from null to a
garbage pointer.
This patch adds checks to avoid emitting relocation records for
non-`Defined` symbols, and to prevent creating an auto-import entry if
an import entry for the wrapped symbol already exists.
Fixes https://github.com/llvm/llvm-project/issues/150739
When `/summary` is used, we now also display the cumulative size of all
input OBJ files, including those pulled from archives. Lazy OBJ files
that were not pulled in are not accounted for.
Also added separators between digit groups, to make the output more
bearable.
Example output:
```
> lld-link ... /summary
Summary
--------------------------------------------------------------------------------
4,958 Input OBJ files (expanded from all cmd-line inputs)
46,715,790,512 Size of all consumed OBJ files (non-lazy), in bytes
42 PDB type server dependencies
0 Precomp OBJ dependencies
293,910,064 Input type records
16,931,361,928 Size of all input type records, in bytes
11,201,549 Merged TPI records
2,765,494 Merged IPI records
38,649 Output PDB strings
21,512,230 Global symbol records
82,380,837 Module symbol records
715,313 Public symbol records
```
I've skipped over the exact amounts for "Size of all consumed inputs
(non-lazy)" in the unit tests, since the sizes of OBJ files can
fluctuate between compilers.
_(this is a reopening of
https://github.com/llvm/llvm-project/pull/157279 which wasa committed by
mistake)_
Those are all MS link.exe compatible flags.
### CET (Control-flow Enforcement Technology) family
- Added LLD test that covers `/cetcompat[:no]`
- Added `/cetcompatstrict[:no]` flag in LLD/COFF
- Added `/cetipvalidationrelaxed[:no]` flag in LLD/COFF
- Added `/cetdynamicapisinproc[:no]` flag in LLD/COFF
### Misc
- Added `/hotpatchcompatible[:no]` flag in LLD/COFF
- This flag requires at least 6 bytes of function padding
(`/functionpadmin:#`) as per link.exe
When `/summary` is used, we now also display the cumulative size of all
input OBJ files, including those pulled from archives. Lazy OBJ files
that were not pulled in are not accounted for.
Also added separators between digit groups, to make the output more
bearable.
Example output:
```
> lld-link ... /summary
Summary
--------------------------------------------------------------------------------
4,958 Input OBJ files (expanded from all cmd-line inputs)
46,715,790,512 Size of all consumed OBJ files (non-lazy), in bytes
42 PDB type server dependencies
0 Precomp OBJ dependencies
293,910,064 Input type records
16,931,361,928 Size of all input type records, in bytes
11,201,549 Merged TPI records
2,765,494 Merged IPI records
38,649 Output PDB strings
21,512,230 Global symbol records
82,380,837 Module symbol records
715,313 Public symbol records
```
We skip over the exact amounts for "Size of all consumed inputs
(non-lazy)" in the unit tests, since the sizes of OBJ files can
fluctuate between compilers.
Previously, llvm-readelf dumped hex format values in different ways.
Some of them were printed in upper-case, while the others were in
lower-case format. This change switches the format to lower-case in all
cases.
Why is this useful? As an example, FileCheck comparisons are
case-sensitive by default. This change means it's easier to compare
those values, because they have the same format.
