D153645 added additional X-Form load/stores that can be generated for TLS accesses.
However, these added instructions have not been accounted for in lld. As a result,
lld does not know how to handle them and cannot relax initial-exec to local-exec
when the initial-exec sequence contains these additional load/stores.
This patch aims to resolve https://github.com/llvm/llvm-project/issues/64424.
Differential Revision: https://reviews.llvm.org/D158197
(cherry picked from commit 698b45aa902de4d30c798e8d6bd080c8e31bade8)
`R_LARCH_PCREL20_S2` is a new added relocation type in LoongArch ELF
psABI v2.10 [1] which is not corvered by D138135 except `R_LARCH_64_PCREL`.
A motivation to support `R_LARCH_PCREL20_S2` in lld is to build the
runtime of .NET core (a.k.a `CoreCLR`) in which strict PC-relative
semantics need to be guaranteed [2]. The normal `pcalau12i + addi.d`
approach doesn't work because the code will be copied to other places
with different "page" and offsets. To achieve this, we can use `pcaddi`
with explicit `R_LARCH_PCREL20_S2` reloc to address +-2MB PC-relative
range with 4-bytes aligned.
[1]: https://github.com/loongson/la-abi-specs/releases/tag/v2.10
[2]: https://github.com/dotnet/runtime/blob/release/7.0/src/coreclr/vm/loongarch64/asmhelpers.S#L307
Reviewed By: xen0n, MaskRay
Differential Revision: https://reviews.llvm.org/D156772
(cherry picked from commit 8a31f7ddb8436fa2a8ad754eb51618139cf63415)
Initially the .rodata section came before .text, hence sharing its
segment with the program header sitting at a small offset, pushing the
output file size to ~72GiB (the file was sparse though, so not much is
really written). This breaks on 32-bit platforms and is irrelevant to
the feature being tested, so re-order the two sections so .text gets
processed first, and both sections get their own segment.
This addresses the issue found by the clang-armv8-lld-2stage builder:
https://lab.llvm.org/buildbot/#/builders/178/builds/5340
Reviewed By: SixWeining, xry111
Differential Revision: https://reviews.llvm.org/D156293
(cherry picked from commit ffe2b6f75de55b665520669059c3d95240482d54)
This adds support for the LoongArch ELF psABI v2.00 [1] relocation
model to LLD. The deprecated stack-machine-based psABI v1 relocs are not
supported.
The code is tested by successfully bootstrapping a Gentoo/LoongArch
stage3, complete with common GNU userland tools and both the LLVM and
GNU toolchains (GNU toolchain is present only for building glibc,
LLVM+Clang+LLD are used for the rest). Large programs like QEMU are
tested to work as well.
[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
Reviewed By: MaskRay, SixWeining
Differential Revision: https://reviews.llvm.org/D138135
SmallVector<*, 0> is often a better replacement for std::vector :
both the object size and the code size are smaller.
(SmallMapVector uses SmallVector as well, but it is not common.)
clang size decreases by 0.0226%.
instructions:u decreases 0.037% when compiling a sqlite3 amalgram.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D156016
There is a strange issue happening with command line processing though. The
command line argument
--export-dynamic-symbol 'f*'
does not have the single quotes stripped on some Windows targets (but not
all). This causes the glob matching to fail, which means the test fails on
some Windows bots and passes on others.
This is expected to be a temporary measure to get bots back to green. I've not
found a commit that has caused a behavioral change that could be reverted
instead, so this could be an issue with lit or test machine configuration.
Similar to recent changes to ELF (e.g., D154813), Mach-O, and COFF to
improve hashing performance.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D155752
For a relocation, we don't differentiate the two cases:
* the symbol index is 0
* the symbol index is non zero, the type is not STT_SECTION, and the name is empty. Clang generates such local symbols for RISC-V linker relaxation.
So we may print
```
Offset Info Type Symbol's Value Symbol's Name + Addend
000000000000001c 0000000100000039 R_RISCV_32_PCREL 0000000000000000 0
// llvm-readobj
0x1C R_RISCV_32_PCREL - 0x0
```
while GNU readelf prints "<null>", which is clearer. Let's match the GNU behavior.
Related to https://reviews.llvm.org/D81842
```
000000000000001c 0000000100000039 R_RISCV_32_PCREL 0000000000000000 <null> + 0
// llvm-readobj
0x1C R_RISCV_32_PCREL <null> 0x0
```
Reviewed By: jhenderson, kito-cheng
Differential Revision: https://reviews.llvm.org/D155353
This reverts commit c9953d9891a6067549a78e7d07ca8eb6a7596792 and a
forward fix in 3a45b843dec1bca195884aa1c5bc56bd0e6755b4.
D14677 causes some failure on windows bots that the forward fix did not
address. Thus I'm reverting until the underlying cause can me triaged.
This patch adds support to lld for --fat-lto-objects. We add a new
--fat-lto-objects flag to LLD, and slightly change how it chooses input
files in the driver when the flag is set.
Fat LTO objects contain both LTO compatible IR, as well as generated object
code. This allows users to defer the choice of whether to use LTO or not to
link-time. This is a feature available in GCC for some time, and makes the
existing -ffat-lto-objects flag functional in the same way as GCC's.
If the --fat-lto-objects option is passed to LLD and the input files are fat
object files, then the linker will chose the LTO compatible bitcode sections
embedded within the fat object and link them together using LTO. Otherwise,
standard object file linking is done using the assembly section in the object
files.
Original RFC: https://discourse.llvm.org/t/rfc-ffat-lto-objects-support/63977
Depends on D146777
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D146778
This is primarily used for .rodata.cst* duplicate elimination. The
sections are usually much smaller than .debug_str (D154813), so the
speedup is negligible. We do this switch for consistency as we want to
eliminate xxh64 in lld.
Detail:
LD64 uses the name provided via -[dylib]install_name as "Identifier", when available.
For compatiblity, LLD should do that too.
Differential Revision: https://reviews.llvm.org/D155508
xxh3 is substantially faster than xxh64.
For lld/ELF, there is substantial speedup in `.debug_str` duplicate
elimination (D154813). Use xxh3 for lld-macho as well.
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D155677
The unified LTO pipeline creates a single LTO bitcode structure that can
be used by Thin or Full LTO. This means that the LTO mode can be chosen
at link time and that all LTO bitcode produced by the pipeline is
compatible, from an optimization perspective. This makes the behavior of
LTO a bit more predictable by normalizing the set of LTO features
supported by each LTO bitcode file.
Example usage:
clang -flto -funified-lto -fuse-ld=lld foo.c
clang -flto=thin -funified-lto -fuse-ld=lld foo.c
clang -c -flto -funified-lto foo.c # -flto={full,thin} are identical in
terms of compilation actions
clang -flto=thin -fuse-ld=lld foo.o # pass --lto=thin to ld.lld
clang -c -flto -funified-lto foo.c clang -flto -fuse-ld=lld foo.o
The RFC discussing the details and rational for this change is here:
https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774
Differential Revision: https://reviews.llvm.org/D123805
We want lld-link to automatically find compiler-rt's and
libc++ when it's in the same directory as the rest of the
toolchain. This is because on Windows linking isn't done
via the clang driver - but instead invoked directly.
This prepends: <llvm>/lib <llvm>/lib/clang/XX/lib and
<llvm>/lib/clang/XX/lib/windows automatically to the library
search paths.
Related to #63827
Differential Revision: https://reviews.llvm.org/D151188
This patch is spun out of https://reviews.llvm.org/D151188
and makes it possible for lld-link to find libraries with
relative paths. This will be used later to implement the
changes to autolinking runtimes explained in #63827
Differential Revision: https://reviews.llvm.org/D155268
While working on adding more implicit search paths to the
lld COFF driver, it was helpful to have a way to print all
the search paths, both for debugging and for testing without
having to create very complicated test cases.
This is a simple arg that just prints the search paths and exits.
Related to the efforts in #63827
Differential Revision: https://reviews.llvm.org/D155047
Annotation attributes may be attached to a function to mark it with
custom data that will be contained in the final Wasm file. The
annotation causes a custom section named
"func_attr.annotate.<name>.<arg0>.<arg1>..." to be created that will
contain each function's index value that was marked with the annotation.
A new patchable relocation type for function indexes had to be created so
the custom section could be updated during linking.
Reviewed By: sbc100
Differential Revision: https://reviews.llvm.org/D150803
In 64 bit mode, any references to symbols that might end up autoimported
must be made via full 64 bit pointers (usually in .refptr stubs
generated by the compiler).
If referenced via e.g. a 32 bit rip relative offset, it might work
as long as DLLs are loaded close together in the 64 bit address
space, but will fail surprisingly later if they happen to be loaded
further apart. Any cases of that happening is usually a toolchain
error, and the sooner we can warn about it, the easier it is to diagnose.
Differential Revision: https://reviews.llvm.org/D154777
Previously, the same file could be used across diagnostic options but
the file would be silently overwritten by the whichever option gets
handled last.
Differential Revision: https://reviews.llvm.org/D153873
Consider a setup without a system-wide installation of lit.
Instead you pass the path to lit like this:
```
cmake ...
-DLLVM_EXTERNAL_LIT=<PATH_TO_LIT_BINARY> ...
```
Then you will run into this error:
```
ninja: error: unknown target 'check-lld'
```
I have a buildbot builder that fails with this message. Here's the
passage that triggers this error:
d3bfd5ccbc/zorg/buildbot/builders/annotated/standalone-build.sh (L194-L239)
By using `LLVM_EXTERNAL_LIT` instead of `LLVM_LIT` we fix this problem.
See
[here](https://llvm.org/docs/GettingStarted.html#stand-alone-builds) for
a description:
> Both the LLVM_ROOT and LLVM_EXTERNAL_LIT options are required to do stand-alone builds for all sub-projects. Additional required options for each sub-project can be found in the table below.
Differential Revision: https://reviews.llvm.org/D154599
This commit provides linker support for Cortex-M Security Extensions (CMSE).
The specification for this feature can be found in ARM v8-M Security Extensions:
Requirements on Development Tools.
The linker synthesizes a security gateway veneer in a special section;
`.gnu.sgstubs`, when it finds non-local symbols `__acle_se_<entry>` and `<entry>`,
defined relative to the same text section and having the same address. The
address of `<entry>` is retargeted to the starting address of the
linker-synthesized security gateway veneer in section `.gnu.sgstubs`.
In summary, the linker translates input:
```
.text
entry:
__acle_se_entry:
[entry_code]
```
into:
```
.section .gnu.sgstubs
entry:
SG
B.W __acle_se_entry
.text
__acle_se_entry:
[entry_code]
```
If addresses of `__acle_se_<entry>` and `<entry>` are not equal, the linker
considers that `<entry>` already defines a secure gateway veneer so does not
synthesize one.
If `--out-implib=<out.lib>` is specified, the linker writes the list of secure
gateway veneers into a CMSE import library `<out.lib>`. The CMSE import library
will have 3 sections: `.symtab`, `.strtab`, `.shstrtab`. For every secure gateway
veneer <entry> at address `<addr>`, `.symtab` contains a `SHN_ABS` symbol `<entry>` with
value `<addr>`.
If `--in-implib=<in.lib>` is specified, the linker reads the existing CMSE import
library `<in.lib>` and preserves the entry function addresses in the resulting
executable and new import library.
Reviewed By: MaskRay, peter.smith
Differential Revision: https://reviews.llvm.org/D139092
Section names used in ELF linker scripts can be quoted, but such
quotes must not be propagated to the binary ELF section names. As
such strip the quotes from the section names when processing them, and
also strip them from linker script functions that take section names
as parameters.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D124266
This patch added /dwodir to lld/COFF which is equivalent to lld/ELF
option -plugin-opt=dwo_dir=. This option tells LTO backend to create
dwo directory and files and all dwo files will be in it. Otherwise all
dwarf sections will be embeded into image even if -gsplit-dwarf is
specified when using LTO.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D154070
This patch adds a thunk for Thumb long branch on V6-M for eXecute Only.
Note that there is currently no support for a position independant and
eXecute Only V6-M long branch thunk
Differential Revision: https://reviews.llvm.org/D153772
With relative vtables the caller jumps directly to the plt entries in the shared object,
therefore landing pad is need for these entries.
Reproducer:
main.cpp
```
#include "v.hpp"
int main() {
A* a = new B();
a->do_something2();
return 0;
}
```
v.hpp
```
struct A {
virtual void do_something() = 0;
virtual void do_something2();
};
struct B : public A {
void do_something() override;
void do_something2() override;
};
```
v.cpp
```
#include "v.hpp"
void A::do_something2() { }
void B::do_something() { }
void B::do_something2() { }
```
```
CC="clang++ --target=aarch64-unknown-linux-gnu -fuse-ld=lld -mbranch-protection=bti"
F=-fexperimental-relative-c++-abi-vtables
${=CC} $F -shared v.cpp -o v.so -z force-bti
${=CC} $F main.cpp -L./ v.so -Wl,-rpath=. -z force-bti
qemu-aarch64-static -L /usr/aarch64-linux-gnu -cpu max ./a.out
```
For v.so, the regular vtable entry is relocated by an R_AARCH64_ABS64 relocation referencing _ZN1B13do_something2Ev.
```
_ZTV1B:
.xword _ZN1B13do_something2Ev
```
Using relative vtable entry for a DSO has a downside of creating many PLT entries and making their addresses escape.
The relative vtable entry references a PLT entry _ZN1B13do_something2Ev@plt.
```
.L_ZTV1A.local:
.word (_ZN1A13do_something2Ev@PLT-.L_ZTV1A.local)-8
```
fixes: #63580
Reviewed By: peter.smith, MaskRay
Differential Revision: https://reviews.llvm.org/D153264
An .ARM.attributes section is divided into subsections, each labelled
with a vendor name. There is one standardised vendor name, which must
be used for all attributes that affect compatibility. Subsections
labelled with other vendor names can be used for optimisation
purposes, but it has to be safe for an object file consumer to ignore
them if it doesn't recognise the vendor name.
LLD currently terminates parsing of the whole attributes section as
soon as it encounters a subsection with a vendor name it doesn't
recognise (which is anything other than the standard one). This can
prevent it from detecting compatibility issues, if a standard
subsection followed the vendor-specific one.
This patch modifies the attribute parser so that unrecognised vendor
subsections are silently skipped, and the subsections beyond them are
still processed.
(Relanded with no change from the original commit 8f208edd44d0832. I
reverted it in 949bb7e4de62cd0 due to widespread buildbot breakage,
failing to notice that 975f71faa72aaaa had already fixed the failing
unit test. Also, the *revert* caused at least one buildbot to fail,
because I switched the affected lld test to making %t a directory, and
then the reverted version tried to treat it as a file without cleaning
the output directory first.)
Differential Revision: https://reviews.llvm.org/D153335
This reverts commit 8f208edd44d0832ac2580e0ec4238be4ecfd5737.
I completely missed the compiled unit test for ELFAttributeParser,
which also needs updating. I'll reland this change once I make further
fixes.
An .ARM.attributes section is divided into subsections, each labelled
with a vendor name. There is one standardised vendor name, which must
be used for all attributes that affect compatibility. Subsections
labelled with other vendor names can be used for optimisation
purposes, but it has to be safe for an object file consumer to ignore
them if it doesn't recognise the vendor name.
LLD currently terminates parsing of the whole attributes section as
soon as it encounters a subsection with a vendor name it doesn't
recognise (which is anything other than the standard one). This can
prevent it from detecting compatibility issues, if a standard
subsection followed the vendor-specific one.
This patch modifies the attribute parser so that unrecognised vendor
subsections are silently skipped, and the subsections beyond them are
still processed.
Differential Revision: https://reviews.llvm.org/D153335
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
This reverts commit 9246df7049b0bb83743f860caff4221413c63de2.
Reason: This patch broke the UBSan buildbots. See more information in
the original phabricator review: https://reviews.llvm.org/D139092
