aboutsummaryrefslogtreecommitdiff
path: root/lld/lib
AgeCommit message (Collapse)AuthorFilesLines
2022-01-05Revert "Revert D109159 "[amdgpu] Enable selection of `s_cselect_b64`.""Nico Weber48-20134/+0
This reverts commit 859ebca744e634dcc89a2294ffa41574f947bd62. The change contained many unrelated changes and e.g. restored unit test failes for the old lld port.
2022-01-05Revert D109159 "[amdgpu] Enable selection of `s_cselect_b64`."David Salinas48-0/+20134
This reverts commit 640beb38e7710b939b3cfb3f4c54accc694b1d30. That commit caused performance degradtion in Quicksilver test QS:sGPU and a functional test failure in (rocPRIM rocprim.device_segmented_radix_sort). Reverting until we have a better solution to s_cselect_b64 codegen cleanup Change-Id: Ibf8e397df94001f248fba609f072088a46abae08 Reviewed By: kzhuravl Differential Revision: https://reviews.llvm.org/D115960 Change-Id: Id169459ce4dfffa857d5645a0af50b0063ce1105
2021-12-02[lld-macho] Remove old macho darwin lldKeith Smiley48-20134/+0
During the llvm round table it was generally agreed that the newer macho lld implementation is feature complete enough to replace the old implementation entirely. This will reduce confusion for new users who aren't aware of the history. Differential Revision: https://reviews.llvm.org/D114842
2021-11-15[NFC][lld] Inclusive language: change master file to merged fileQuinn Pham2-2/+2
[NFC] As part of using inclusive language within the llvm project, this patch replaces master with merged in these comments. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D113903
2021-10-18Use llvm::erase_if (NFC)Kazu Hirata1-15/+8
2021-08-04[CMake][gn] lldMachO=>lldMachOOld, lldMachO2=>lldMachOFangrui Song2-2/+2
Now that D95204 switched default to new Darwin backend, rename some CMake targets to match. Reviewed By: #lld-macho, smeenai, int3 Differential Revision: https://reviews.llvm.org/D107516
2021-06-24[OptTable] Rename PrintHelp to printHelpFangrui Song1-1/+1
To be consistent with other member functions and match the coding standard.
2021-06-25[lld] Rename StringRef _lower() method calls to _insensitive()Martin Storsjö1-1/+1
2021-04-26[NFC] Fix "not used" warningVitaly Buka1-2/+1
2021-04-06[SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag ↵Abhina Sreeskantharajan1-1/+1
instead of OF_Text Problem: On SystemZ we need to open text files in text mode. On Windows, files opened in text mode adds a CRLF '\r\n' which may not be desirable. Solution: This patch adds two new flags - OF_CRLF which indicates that CRLF translation is used. - OF_TextWithCRLF = OF_Text | OF_CRLF indicates that the file is text and uses CRLF translation. Developers should now use either the OF_Text or OF_TextWithCRLF for text files and OF_None for binary files. If the developer doesn't want carriage returns on Windows, they should use OF_Text, if they do want carriage returns on Windows, they should use OF_TextWithCRLF. So this is the behaviour per platform with my patch: z/OS: OF_None: open in binary mode OF_Text : open in text mode OF_TextWithCRLF: open in text mode Windows: OF_None: open file with no carriage return OF_Text: open file with no carriage return OF_TextWithCRLF: open file with carriage return The Major change is in llvm/lib/Support/Windows/Path.inc to only set text mode if the OF_CRLF is set. ``` if (Flags & OF_CRLF) CrtOpenFlags |= _O_TEXT; ``` These following files are the ones that still use OF_Text which I left unchanged. I modified all these except raw_ostream.cpp in recent patches so I know these were previously in Binary mode on Windows. ./llvm/lib/Support/raw_ostream.cpp ./llvm/lib/TableGen/Main.cpp ./llvm/tools/dsymutil/DwarfLinkerForBinary.cpp ./llvm/unittests/Support/Path.cpp ./clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp ./clang/lib/Frontend/CompilerInstance.cpp ./clang/lib/Driver/Driver.cpp ./clang/lib/Driver/ToolChains/Clang.cpp Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D99426
2021-04-05[TextAPI] move source code files out of subdirectory, NFCCyndy Ishida1-2/+2
TextAPI/ELF has moved out into InterfaceStubs, so theres no longer a need to seperate out TextAPI between formats. Reviewed By: ributzka, int3, #lld-macho Differential Revision: https://reviews.llvm.org/D99811
2020-12-28[MachO] Fix enum-int mismatch warningGabriel Hjort Åkerlund1-1/+1
Change-Id: Ie637dc7761144e5552b05a9c286f1e736579823d Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D91520
2020-10-20Reland "[yaml2obj][ELF] - Simplify the code that performs sections validation."Georgii Rymar1-3/+1
This reverts commit 1b589f4d4db27e3fcd81fdc5abeb9407753ab790 and relands the D89463 with the fix: update `MappingTraits<FileFilter>::validate()` in ClangTidyOptions.cpp to match the new signature (change the return type to "std::string" from "StringRef"). Original commit message: This: Changes the return type of MappingTraits<T>>::validate to std::string instead of StringRef. It allows to create more complex error messages. It introduces std::vector<std::pair<StringRef, bool>> getEntries(): a new virtual method of Section, which is the base class for all sections. It returns names of special section specific keys (e.g. "Entries") and flags that says if them exist in a YAML. The code in validate() uses this list of entries descriptions to generalize validation. This approach was discussed in the D89039 thread. Differential revision: https://reviews.llvm.org/D89463
2020-10-20Revert "[yaml2obj][ELF] - Simplify the code that performs sections validation."Georgii Rymar1-1/+3
This reverts commit b9e2b59680ad1bbfd2b9110b3ebf3d2b22cad51b.
2020-10-20[yaml2obj][ELF] - Simplify the code that performs sections validation.Georgii Rymar1-3/+1
This: 1) Changes the return type of `MappingTraits<T>>::validate` to `std::string` instead of `StringRef`. It allows to create more complex error messages. 2) It introduces std::vector<std::pair<StringRef, bool>> getEntries(): a new virtual method of Section, which is the base class for all sections. It returns names of special section specific keys (e.g. "Entries") and flags that says if them exist in a YAML. The code in validate() uses this list of entries descriptions to generalize validation. This approach was discussed in the D89039 thread. Differential revision: https://reviews.llvm.org/D89463
2020-09-24[LLD][COFF] Cover usage of LLD-as-a-library in testsAlexandre Ganea1-0/+1
In lit tests, we run each LLD invocation twice (LLD_IN_TEST=2), without shutting down the process in-between. This ensures a full cleanup is properly done between runs. Only active for the COFF driver for now. Other drivers still use LLD_IN_TEST=1 which executes just one iteration with full cleanup, like before. When the environment variable LLD_IN_TEST is unset, a shortcut is taken, only one iteration is executed, no cleanup for faster exit, like before. A public API, lld::safeLldMain(), is also available when using LLD as a library. Differential Revision: https://reviews.llvm.org/D70378
2020-07-17[CMake] Make `intrinsics_gen` dependency unconditional.Michele Scandale1-5/+1
The `intrinsics_gen` target exists in the CMake exports since r309389 (see LLVMConfig.cmake.in), hence projects can depend on `intrinsics_gen` even it they are built separately from LLVM. Reviewed By: MaskRay, JDevlieghere Differential Revision: https://reviews.llvm.org/D83454
2020-07-02ld64.lld: Make janky support for tbd files actually work sometimesNico Weber1-1/+1
Also fix a bug in the test input that made the test miss this issue.
2020-07-02[LLD] Add required dependency after shared libs break due to ba5087f13025Nemanja Ivanovic1-0/+1
The dependency on TextAPI was not added and is required for shared libs builds.
2020-07-02ld64.lld: Add janky support for tbd filesNico Weber5-17/+114
With this, a simple hello world links against libSystem.tbd and the old ld64.lld linker kind of works again with newer SDKs. The motivation here is to have an arm64 cross linker that's good enough to be able to run simple configure link checks on non-mac systems for generating config.h files. Once -flavor darwinnew can link arm64, we'll switch to that.
2020-06-19[lld] As part of using inclusive language within the llvmEric Christopher3-13/+13
project, migrate away from the use of blacklist and whitelist.
2020-06-03lld: use `std::make_unique` (NFC)Saleem Abdulrasool1-2/+2
The LLVM code base already uses C++14, use std::make_unique to avoid the explicit constructor invocation via new and to avoid spelling out the type twice.
2020-05-05[Support] Move LLD's parallel algorithm wrappers to supportReid Kleckner1-4/+5
Essentially takes the lld/Common/Threads.h wrappers and moves them to the llvm/Support/Paralle.h algorithm header. The changes are: - Remove policy parameter, since all clients use `par`. - Rename the methods to `parallelSort` etc to match LLVM style, since they are no longer C++17 pstl compatible. - Move algorithms from llvm::parallel:: to llvm::, since they have "parallel" in the name and are no longer overloads of the regular algorithms. - Add range overloads - Use the sequential algorithm directly when 1 thread is requested (skips task grouping) - Fix the index type of parallelForEachN to size_t. Nobody in LLVM was using any other parameter, and it made overload resolution hard for for_each_n(par, 0, foo.size(), ...) because 0 is int, not size_t. Remove Threads.h and update LLD for that. This is a prerequisite for parallel public symbol processing in the PDB library, which is in LLVM. Reviewed By: MaskRay, aganea Differential Revision: https://reviews.llvm.org/D79390
2020-04-04fix typo in comment to cycle botsNico Weber2-2/+2
2020-04-02[lld] NFC: fix trivial typos in commentsKazuaki Ishizaki4-7/+7
Differential Revision: https://reviews.llvm.org/D72339
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer5-11/+12
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-06[lld] Fix trivial typos in commentsKazuaki Ishizaki9-17/+17
Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D72196
2020-01-01[lld] Fix -Wrange-loop-analysis warningsFangrui Song1-1/+1
One instance looks like a false positive: lld/ELF/Relocations.cpp:1622:14: note: use reference type 'const std::pair<ThunkSection *, uint32_t> &' (aka 'cons t pair<lld::elf::ThunkSection *, unsigned int> &') to prevent copying for (const std::pair<ThunkSection *, uint32_t> ts : isd->thunkSections) It is not changed in this commit.
2019-12-17[MachO] Fix detecting malformed DWARF.Igor Kudrin1-2/+2
This fixes an invalid constant used to detect the reserved range when reading the compilation unit header. See also: D64622 and D65039. Differential Revision: https://reviews.llvm.org/D71546
2019-11-21LLD: Don't use the stderrOS stream in link before it's reassigned.James Y Knight1-4/+4
Remove the lld::enableColors function, as it just obscures which stream it's affecting, and replace with explicit calls to the stream's enable_colors. Also, assign the stderrOS and stdoutOS globals first in link function, just to ensure nothing might use them. (Either change individually fixes the issue of using the old stream, but both together seems best.) Follow-up to b11386f9be9b2dc7276a758d64f66833da10bdea. Differential Revision: https://reviews.llvm.org/D70492
2019-11-19Revert "Fix shared lib build."Rui Ueyama2-4/+2
This reverts commit 17e37ba57a696198c9744eeba4f8f293f155587a because it introduced a circular dependency between Core and Common. Because d0371f473675ede1d79a615ec4fdf0cf5368944c fixed a build issue, we no longer need that dependency.
2019-11-19Fix component buildRui Ueyama7-25/+25
b11386f9be9b2dc7276a758d64f66833da10bdea broke lld build if `-DBUILD_SHARED_LIBS=ON` is passed to CMake.
2019-11-18Fix shared lib build.Michael Liao2-2/+4
2019-11-18Make it possible to redirect not only errs() but also outs()Rui Ueyama7-44/+36
This change is for those who use lld as a library. Context: https://reviews.llvm.org/D70287 This patch adds a new parmeter to lld::*::link() so that we can pass an raw_ostream object representing stdout. Previously, lld::*::link() took only an stderr object. Justification for making stdoutOS and stderrOS mandatory: I wanted to make link() functions to take stdout and stderr in that order. However, if we change the function signature from bool link(ArrayRef<const char *> args, bool canExitEarly, raw_ostream &stderrOS = llvm::errs()); to bool link(ArrayRef<const char *> args, bool canExitEarly, raw_ostream &stdoutOS = llvm::outs(), raw_ostream &stderrOS = llvm::errs()); , then the meaning of existing code that passes stderrOS silently changes (stderrOS would be interpreted as stdoutOS). So, I chose to make existing code not to compile, so that developers can fix their code. Differential Revision: https://reviews.llvm.org/D70292
2019-10-19Move endian constant from Host.h to SwapByteOrder.h, prune includeReid Kleckner1-0/+1
Works on this dependency chain: ArrayRef.h -> Hashing.h -> --CUT-- Host.h -> StringMap.h / StringRef.h ArrayRef is very popular, but Host.h is rarely needed. Move the IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are more likely to need it. llvm-svn: 375316
2019-09-26[lld][mach-o] Avoid segfaulting when handling an empty section list.Matt Davis1-6/+8
Summary: The following patch avoids segfaulting if the section list is empty when writing a mach-o MH_OBJECT. I ran into this case from a more complicated example trying to dead_strip while using '-r' in lld. I'm not sure if having empty sections is a legal mach-o, but it does seem that other llvm-binutils tools can ingest such a boring object with out issue. Would it be better to emit an error, emit a warning, or do nothing? It seems that adding a warning diagnostic might be helpful to users, as I did not expect to have a section-less object when the linker was done. Reviewers: kledzik, ruiu Subscribers: llvm-commits, jrm Tags: #lld, #llvm Differential Revision: https://reviews.llvm.org/D67735 llvm-svn: 372995
2019-08-28[mach-o] Extend LC_DATA_IN_CODE support to x86_64Rui Ueyama1-8/+42
Patch by LemonBoy Differential Revision: https://reviews.llvm.org/D62185 llvm-svn: 370183
2019-08-14[LLD] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere11-20/+20
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368936
2019-08-07Re-submit r367649: Improve raw_ostream so that you can "write" colors using ↵Rui Ueyama1-1/+1
operator<< The original patch broke buildbots, perhaps because it changed the default setting whether colors are enabled or not. llvm-svn: 368131
2019-08-06[MachO] Update LLD to use 64-bit offsets with DataExtractor (3/5)Igor Kudrin1-6/+6
Differential Revision: https://reviews.llvm.org/D65639 llvm-svn: 368032
2019-08-05Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2-3/+3
F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
2019-08-02Revert r367649: Improve raw_ostream so that you can "write" colors using ↵Rui Ueyama1-0/+1
operator<< This reverts commit r367649 in an attempt to unbreak Windows bots. llvm-svn: 367658
2019-08-02Improve raw_ostream so that you can "write" colors using operator<<Rui Ueyama1-1/+0
1. raw_ostream supports ANSI colors so that you can write messages to the termina with colors. Previously, in order to change and reset color, you had to call `changeColor` and `resetColor` functions, respectively. So, if you print out "error: " in red, for example, you had to do something like this: OS.changeColor(raw_ostream::RED); OS << "error: "; OS.resetColor(); With this patch, you can write the same code as follows: OS << raw_ostream::RED << "error: " << raw_ostream::RESET; 2. Add a boolean flag to raw_ostream so that you can disable colored output. If you disable colors, changeColor, operator<<(Color), resetColor and other color-related functions have no effect. Most LLVM tools automatically prints out messages using colors, and you can disable it by passing a flag such as `--disable-colors`. This new flag makes it easy to write code that works that way. Differential Revision: https://reviews.llvm.org/D65564 llvm-svn: 367649
2019-07-11[Coding style change][lld] Rename variables for non-ELF portsRui Ueyama1-12/+12
This patch does the same thing as r365595 to other subdirectories, which completes the naming style change for the entire lld directory. With this, the naming style conversion is complete for lld. Differential Revision: https://reviews.llvm.org/D64473 llvm-svn: 365730
2019-04-23Use llvm::stable_sortFangrui Song1-5/+4
Make some small adjustment while touching the code: make parameters const, use less_first(), etc. Differential Revision: https://reviews.llvm.org/D60989 llvm-svn: 358943
2019-04-17lld: Fix initial Mach-O load commands size calculation omitting ↵Rui Ueyama3-12/+21
LC_FUNCTION_STARTS Patch by Nicholas Allegra. The Mach-O writer calculates the size of load commands multiple times. First, Util::assignAddressesToSections() (in MachONormalizedFileFromAtoms.cpp) calculates the size using headerAndLoadCommandsSize() (in MachONormalizedFileBinaryWriter.cpp), which creates a temporary MachOFileLayout for the NormalizedFile, only to retrieve its headerAndLoadCommandsSize. Later, writeBinary() (in MachONormalizedFileBinaryWriter.cpp) creates a new layout and uses the offsets from that layout to actually write out everything in the NormalizedFile. But the NormalizedFile changes between the first computation and the second. When Util::assignAddressesToSections is called, file.functionStarts is always empty because Util::addFunctionStarts has not yet been called. Yet MachOFileLayout decides whether to include a LC_FUNCTION_STARTS command based on whether file.functionStarts is nonempty. Therefore, the initial computation always omits it. Because padding for the __TEXT segment (to make its size a multiple of the page size) is added between the load commands and the first section, LLD still generates a valid binary as long as the amount of padding happens to be large enough to fit LC_FUNCTION_STARTS command, which it usually is. However, it's easy to reproduce the issue by adding a section of a precise size. Given foo.c: __attribute__((section("__TEXT,__foo"))) char foo[0xd78] = {0}; Run: clang -dynamiclib -o foo.dylib foo.c -fuse-ld=lld -install_name /usr/lib/foo.dylib otool -lvv foo.dylib This should produce: truncated or malformed object (offset field of section 1 in LC_SEGMENT_64 command 0 not past the headers of the file) This commit: - Changes MachOFileLayout to always assume LC_FUNCTION_STARTS is present for the initial computation, as long as generating LC_FUNCTION_STARTS is enabled. It would be slightly better to check whether there are actually any functions, since no LC_FUNCTION_STARTS will be generated if not, but it doesn't cause a problem if the initial computation is too high. - Adds a test. - Adds an assert in MachOFileLayout::writeSectionContent() that we are not writing section content into the load commands region (which would happen if the offset was calculated too low due to the initial load commands size calculation being too low). Adds an assert in MachOFileLayout::writeLoadCommands to validate a similar situation where two size-of-load-commands computations are expected to be equivalent. llvm-svn: 358545
2019-03-29[ELF][MachO][wasm] Simplify range-style std::find{,_if} with STLExtras.h ↵Fangrui Song3-13/+7
utilities. NFC llvm-svn: 357269
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth41-164/+123
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-11-01Fix clang -Wimplicit-fallthrough warnings across llvm, NFCReid Kleckner2-0/+2
This patch should not introduce any behavior changes. It consists of mostly one of two changes: 1. Replacing fall through comments with the LLVM_FALLTHROUGH macro 2. Inserting 'break' before falling through into a case block consisting of only 'break'. We were already using this warning with GCC, but its warning behaves slightly differently. In this patch, the following differences are relevant: 1. GCC recognizes comments that say "fall through" as annotations, clang doesn't 2. GCC doesn't warn on "case N: foo(); default: break;", clang does 3. GCC doesn't warn when the case contains a switch, but falls through the outer case. I will enable the warning separately in a follow-up patch so that it can be cleanly reverted if necessary. Reviewers: alexfh, rsmith, lattner, rtrieu, EricWF, bollu Differential Revision: https://reviews.llvm.org/D53950 llvm-svn: 345882
2018-10-10Eliminate dependency to formatv(). NFC.Rui Ueyama1-4/+3
llvm-svn: 344177