aboutsummaryrefslogtreecommitdiff
path: root/lld
AgeCommit message (Collapse)AuthorFilesLines
2023-10-10[LLD] [COFF] Fix handling of comdat .drectve sections (#68116)Martin Storsjö2-0/+33
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. (cherry picked from commit 503bc5f66111f7e4fc79972bb9bfec8bb5606bab)
2023-10-02[LLD] [COFF] Restore the current dir as the first entry in the search path ↵Martin Storsjö2-11/+8
(#67857) Before af744f0b84e2b6410be65277068b9033124c73b2, the first entry among the search paths was the empty string, indicating searching in (or starting from) the current directory. After af744f0b84e2b6410be65277068b9033124c73b2, the toolchain/clang specific lib directories were added at the head of the search path. This would cause lookups of literal file names or relative paths to match paths in the toolchain, if there are coincidental files with similar names there, even if they would be find in the current directory as well. Change addClangLibSearchPaths to append to the list like all other operations on searchPaths - but move the invocation of the function to the right place in the sequence. This fixes #67779. (cherry picked from commit f906fd53b5ce12f07aec394ddf900c7f9f583405)
2023-10-02[LLD] [COFF] Clarify -print-search-path for the empty string element (#67856)Martin Storsjö2-15/+22
Also switch the test case to use -NEXT to strictly match all lines. (cherry picked from commit 7d7d9e462a8983d71e01786c9ad61a976ff10e8a)
2023-10-02[NFC] clang-format lld/COFF/Driver.cpp and lld/Common/Filesystem.cppMatheus Izvekov2-16/+18
In order to reduce noise for a MR. (cherry picked from commit a5e280bc6bda10607e0e7c864e4d23fac02d00aa)
2023-09-28[lld][COFF] Remove incorrect flag from EHcont tablenamazso2-171/+41
Fixes EHCont implementation in LLD. Closes #64570 Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D157623 (cherry picked from commit e335c78ec2848e24b10e32e015a84347c69c8130)
2023-09-01[PowerPC][lld] Account for additional X-Forms -> D-Form/DS-Forms load/stores ↵Amy Kwan6-43/+287
when relaxing initial-exec to local-exec 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)
2023-08-11[lld][LoongArch] Support the R_LARCH_PCREL20_S2 relocation typeWeining Lu2-0/+39
`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)
2023-07-31[docs] Add release notes for a Windows specific change in LLDMartin Storsjö1-0/+5
2023-07-27[lld][ELF][test] Fix excessive output file size in loongarch-add-sub.sWANG Xuerui1-4/+4
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)
2023-07-25[lld][ELF] Support LoongArchWANG Xuerui29-26/+2064
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
2023-07-24[Support] Change MapVector's default template parameter to SmallVector<*, 0>Fangrui Song1-1/+1
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
2023-07-23ReleaseNotes: add lld/ELF notesFangrui Song1-0/+54
2023-07-22[WebAssembly] Stabilize custom section orderFangrui Song4-11/+12
It currently depends on the StringMap iteration order, which is not guaranteed to be deterministic. Use MapVector to stabilize the order.
2023-07-21Mark this test as unsupported on Windows systemsAaron Ballman1-0/+10
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.
2023-07-20[wasm-ld] Switch to xxh3_64bitsFangrui Song3-4/+4
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
2023-07-20[llvm-readobj] Print <null> for relocation target with an empty nameFangrui Song1-2/+2
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
2023-07-20Revert "[lld] Preliminary fat-lto-object support"Paul Kirth7-147/+6
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.
2023-07-19[ELF][test] Add REQUIRES: x86 after D146778Fangrui Song1-0/+1
2023-07-19[lld-macho] Use fixed chunk size for UUIDFangrui Song1-4/+1
Chunk size decided by the thread count makes the UUID less deterministic (e.g. across machines with different core counts.) Follow ELF and just use a fixed chunksize. Fixes: https://github.com/llvm/llvm-project/issues/63961 Reviewed By: #lld-macho, keith Differential Revision: https://reviews.llvm.org/D155761
2023-07-19[lld-macho] Implement -no_uuidKeith Smiley5-4/+11
Since UUID generation in lld is fast this is rarely used but it can be helpful to avoid temporary issues like https://github.com/llvm/llvm-project/issues/63961 Differential Revision: https://reviews.llvm.org/D155735
2023-07-19[lld] Preliminary fat-lto-object supportPaul Kirth7-6/+146
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
2023-07-19[COFF] Switch to xxh3_64bitsFangrui Song3-15/+13
Similar to recent changes to ELF (e.g., commit f4b4bc2f18dc0e44afde05735fb673d3de4d5c39) and Mach-O to improve hashing performance.
2023-07-19[ELF] --build-id=fast: switch to xxh3_64bitsFangrui Song2-2/+2
2023-07-19[ELF] splitNonStrings: switch to xxh3_64bitsFangrui Song7-33/+33
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.
2023-07-19[lld-macho]Use install_name as Identifier for code-sign, if available.Vy Nguyen2-2/+28
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
2023-07-19[ELF][test] Refactor merge.sFangrui Song1-52/+11
2023-07-19[lld-macho] Switch to xxh3_64bitsFangrui Song4-7/+7
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
2023-07-19[ELF] Use llvm::xxh3_64bits for MergeInputSection::splitStringsFangrui Song5-13/+14
See D154812 for the speedup. Reviewed By: PiotrZSL Differential Revision: https://reviews.llvm.org/D154813
2023-07-18[ELF] --icf: switch to xxh3_64bitsFangrui Song4-89/+80
for more efficient section content hashing. Also clean up the tests a bit and properly test the formatting of --print-icf-sections.
2023-07-18[lld] A Unified LTO Bitcode FrontendMatthew Voss5-2/+64
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
2023-07-18[lld][test] Remove unused featuresFangrui Song1-8/+0
"system-linker-elf" and "demangler" have been unused since lld/test/old-elf/ was removed in 2016.
2023-07-15[ELF] Support operator ^ and ^=Fangrui Song6-18/+39
GNU ld added ^ support in July 2023 and it looks like ^= is in plan as well. For now, we don't support `a^=0` (^= without a preceding space).
2023-07-14[LLD][COFF] Add LLVM toolchain library paths by default.Tobias Hieta4-0/+40
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
2023-07-14[lld][COFF] Find libraries with relative paths.Tobias Hieta3-2/+11
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
2023-07-13[lld][COFF] Add -print-search-paths for debugging.Tobias Hieta4-0/+35
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
2023-07-11[WebAssembly] Support `annotate` clang attributes for marking functions.Brendan Dahl5-6/+137
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
2023-07-11[LLD] [COFF] Warn about pseudo relocations that are too narrowMartin Storsjö4-0/+56
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
2023-07-11[ELF] Make subsequent opens to auxiliary files appendAlex Brachet4-4/+36
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
2023-07-06[ELF] Use compression::getReasonIfUnsupported for zlib/zstd unavailable errorFangrui Song2-15/+27
The error message now matches llvm-objcopy --compress-debug-sections=[zlib|zstd].
2023-07-06[lld] respect LLVM_EXTERNAL_LITKonrad Kleine1-3/+3
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: https://github.com/llvm/llvm-zorg/blob/d3bfd5ccbceb542098c350e4d071ceceac6854cb/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
2023-07-06[LLD][ELF] Cortex-M Security Extensions (CMSE) SupportAmilendra Kodithuwakku22-2/+1195
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
2023-07-05[ELF] Remove one unneeded unquote from D124266Fangrui Song1-1/+1
This one is unneeded after commit d60ef9338deb734541ff1c9d0771807815d5d9e6 (2023-02-03).
2023-07-05[lld/elf] support quote usage in section namesRoger Pau Monne2-5/+52
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
2023-07-01[lld/COFF] Add /dwodir to enable DWARF fission with LTOHaohai Wen5-0/+27
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
2023-06-30[ARM] armv6m eXecute Only (XO) long branch ThunkKeith Walker2-6/+113
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
2023-06-29[lld][AArch64] Add BTI landing pad to PLT entries when the symbol is exported.Daniel Kiss2-2/+50
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
2023-06-29[ELF][NFC] Change comment terminologyAlex Brachet1-1/+1
Differential Revision: https://reviews.llvm.org/D153978
2023-06-27[test] Replace aarch64-arm-none-eabi with aarch64Fangrui Song1-1/+1
Similar to 02e9441d6ca73314afa1973a234dce1e390da1da, but for llvm/test and one lld/test/ELF test.
2023-06-27Reland: [ELFAttributeParser] Skip unknown vendor subsections.Simon Tatham1-10/+68
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
2023-06-27Revert "[ELFAttributeParser] Skip unknown vendor subsections."Simon Tatham1-68/+10
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.
generated by cgit v1.1 at 2024-09-17 15:18:44 +0000