This is achieved by using some of the bits of RelType to tag vendor namespaces. This change also adds a relocation iterator for RISCV that folds vendor namespaces into the RelType of the following relocation.
This patch is extracted from the implementation of RISCV vendor-specific relocations in the CHERIoT LLVM downstream: 3d6d6f7d94
When wrapping a symbol `foo` via `-wrap=foo`, we create the symbol
`__wrap_foo` that replaces all mentions of `foo`. This feature was
implemented for wasm-ld in commit a5ca34e.
So far, no valid signature has been attached to the undefined symbol,
leading to a nullptr dereference in the logic for creating the import
section. This change adds the correct signature to the wrapped symbol,
enabling the generation of an import for it.
Further to
https://github.com/llvm/llvm-project/pull/147134#discussion_r2337246489,
switch to use the madvise() api to page in mmap'd files and
1) All new code compiled in #if LLVM_ENABLE_THREADS is set so it can be
seen where the changes were from this PR.
2) 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.
3) A new property SerialBackgroundQueue().stopAllWork to be used to stop
background workers when there is no further call for them. Usually the
background "page-in" threads have completed first but it seems with this
troublesome test this is not always the case and buffers stored in the
static input file cache are being deallocated while being referenced.
---------
Co-authored-by: James Henderson <James.Henderson@sony.com>
I noticed that we had a hardcoded value of 4 for the pcrel section
relocations, which seems like an issue given that we recently added
support for 1-byte branch relocations in
https://github.com/llvm/llvm-project/pull/164439. The code included an
assert that the relevant relocation had the BYTE4 attribute, but that is
actually not enough to use a hardcoded value of 4: we need to assert
that the *other* `BYTE<n>` attributes are not set either.
However, since we did not support local branch relocations, that doesn't
seem to have mattered in practice. That said, local branch relocations
can be emitted by compilers, and ld64 does handle the 4-byte version of
them, so I've added support for it here.
ld64 actually seems to reject 1-byte section relocations, so the
questionable code is actually probably fine (minus the incorrect
assert). So we have two options: add an equivalent check in LLD, or just
support 1-byte local branch relocations. Supporting it actually requires
less code, so I've gone with that option here.
The GNU documentation is ambiguous about the version index for
unversioned undefined symbols. The current specification at
https://sourceware.org/gnu-gabi/program-loading-and-dynamic-linking.txt
defines VER_NDX_LOCAL (0) as "The symbol is private, and is not
available outside this object."
However, this naming is misleading for undefined symbols. As suggested
in
discussions, VER_NDX_LOCAL should conceptually be VER_NDX_NONE and apply
to unversioned undefined symbols as well.
GNU ld has used index 0 for unversioned undefined symbols both before
version 2.35 (see https://sourceware.org/PR26002) and in the upcoming
2.46 release (see https://sourceware.org/PR33577). This change aligns
with GNU ld's behavior by switching from index 1 to index 0.
While here, add a test to dso-undef-extract-lazy.s that undefined
symbols of index 0 in DSO are treated as unversioned symbols.
Currently, if multiple external weak symbols are defined at the same
address in an object file (e.g., by using the .set assembler directive
to alias them to a single weak variable), ld64.lld treats them as a
single unit. When any one of these symbols is overridden by a strong
definition, all of the original weak symbols resolve to the strong
definition.
This patch changes the behavior in `transplantSymbolsAtOffset`. When a
weak symbol is being replaced by a strong one, only non-external (local)
symbols at the same offset are moved to the new symbol's section. Other
*external* symbols are no longer transplanted.
This allows each external weak symbol to be overridden independently.
This behavior is consistent with Apple's ld-classic, but diverges from
ld-prime in one case, as noted on
https://github.com/llvm/llvm-project/issues/167262 (this discrepancy has
recently been reported to Apple).
### Backward Compatibility
This change alters linker behavior for a specific scenario. The creation
of multiple external weak symbols aliased to the same address via
assembler directives is primarily an advanced technique. It's unlikely
that existing builds rely on the current behavior of all aliases being
overridden together.
If there are concerns, this could be put behind a linker option, but the
new default seems more correct, less surprising, and is consistent with
ld-classic.
### Testing
The new lit test `test/MachO/weak-alias-override.s` verifies this
behavior using llvm-nm.
Fixes#167262
Various build tools may produce command lines invoking clang-cl and
lld-link which contain /link twice like so: e.g. `clang-cl.exe
sanitycheckcpp.cc /Fesanitycheckcpp.exe .... /link /link ...`
If link.exe is used, it ignores the extra `/link` and just issues a
warning, however lld-link tries to treat `/link` as a file name.
This PR adds a flag which is ignored in order to improve compatibility
with link.exe
There's some extra context including an "in-the-wild" example and
reproducer of the problem here:
https://github.com/frankier/meson_clang_win_activation
Co-authored-by: Frankie Robertson <frankie@robertson.name>
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
