| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[LLD][COFF] Fix writing a map file when range extension thunks are inserted Bug: An assertion fails: Assertion failed: isa<To>(Val) && "cast<Ty>() argument of incompatible type!", file C:\Users\<user>\prog\llvm\llvm-git-lld-bug\llvm\include\llvm/Support/Casting.h, line 578 Bug is triggered, if - a map file is requested with /MAP, and - Architecture is ARMv7, Thumb, and - a relative jump (branch instruction) is greater than 16 MiB (2^24) The reason for the Bug is: - a Thunk is created for the jump - a Symbol for the Thunk is created - of type DefinedSynthetic - in file Writer.cpp - in function getThunk - the Symbol has no name - when creating the map file, the name of the Symbol is queried - the function Symbol::computeName of the base class Symbol casts the this pointer to type DefinedCOFF (a derived type), but the acutal type is DefinedSynthetic - The in the llvm::cast an assertion fails Changes: - Modify regression test to trigger this bug - Give the symbol pointing to the thunk a name, to fix the bug - Add assertion, that only DefinedCOFF symbols are allowed to have an empty name, when the constructor of the base class Symbol is executed Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D133201 (cherry picked from commit 4e5a59a3839f54d928d37d49d4c4ddbb3f339b76) | 3 年前 | |
[lld-macho] Add support for -w This flag suppresses warnings produced by the linker. In ld64 this has an interesting interaction with -fatal_warnings, it silences the warnings but the link still fails. Instead of doing that here we still print the warning and eagerly fail the link in case both are passed, this seems more reasonable so users can understand why the link fails. Differential Revision: https://reviews.llvm.org/D127564 | 3 年前 | |
fix: all visible packdges Signed-off-by: wzy_00889928 <1322947566@qq.com> | 1 个月前 | |
fix: delete useless warning Signed-off-by: jinbohang <jinbohang1@huawei.com> | 9 天前 | |
[LLD] [MinGW] Implement the --exclude-symbols option This adds support for the existing GNU ld command line option, which allows excluding individual symbols from autoexport (when linking a DLL and no symbols are marked explicitly as dllexported). Differential Revision: https://reviews.llvm.org/D130118 (cherry picked from commit d1da6469f9ea9b078276ee2e098241f0440468be) | 3 年前 | |
[CMake] Fix add_subdirectory llvm builds Fixes a regression from D117973, that used CMAKE_BINARY_DIR instead of LLVM_BINARY_DIR in some places. Differential Revision: https://reviews.llvm.org/D130555 | 3 年前 | |
[DOCS] Minor fixes and removals of WIP warnings | 3 年前 | |
[NFC][lld] Fix typos to test commit access | 3 年前 | |
fix: allow linking with ABI compatible architectures for xcode 26.4 Signed-off-by: neilliuistaken <liujiajie12@huawei.com> | 2 个月前 | |
Init project. | 10 个月前 | |
Python 2/3 compatibility This should be the only change required to have lld's python code base compatible with both Python 2 and Python 3 Differential Revision: https://reviews.llvm.org/D59538 llvm-svn: 356538 | 7 年前 | |
Use any_of (NFC) | 3 年前 | |
Remove redundant "Standard: Cpp11" tag. The LLVM style has used the Cpp11 standard since r202637. llvm-svn: 212336 | 11 年前 | |
NFC: .clang-tidy: Inherit configs from parents to improve maintainability In the interests of disabling misc-no-recursion across LLVM (this seems like a stylistic choice that is not consistent with LLVM's style/development approach) this NFC preliminary change adjusts all the .clang-tidy files to inherit from their parents as much as possible. This change specifically preserves all the quirks of the current configs in order to make it easier to review as NFC. I validatad the change is NFC as follows: for X in cat ../files.txt; do mkdir -p ../tmp/$(dirname $X) touch $(dirname $X)/blaikie.cpp clang-tidy -dump-config $(dirname $X)/blaikie.cpp > ../tmp/$(dirname $X)/after rm $(dirname $X)/blaikie.cpp done (similarly for the "before" state, without this patch applied) for X in cat ../files.txt; do echo $X diff \ ../tmp/$(dirname $X)/before \ <(cat ../tmp/$(dirname $X)/after \ | sed -e "s/,readability-identifier-naming\(.*\),-readability-identifier-naming/\1/" \ | sed -e "s/,-llvm-include-order\(.*\),llvm-include-order/\1/" \ | sed -e "s/,-misc-no-recursion\(.*\),misc-no-recursion/\1/" \ | sed -e "s/,-clang-diagnostic-\*\(.*\),clang-diagnostic-\*/\1/") done (using sed to strip some add/remove pairs to reduce the diff and make it easier to read) The resulting report is: .clang-tidy clang/.clang-tidy 2c2 < Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-readability-identifier-naming,-misc-no-recursion' --- > Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-misc-no-recursion' compiler-rt/.clang-tidy 2c2 < Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,-llvm-header-guard,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes' --- > Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,clang-diagnostic-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-header-guard' flang/.clang-tidy 2c2 < Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,-llvm-include-order,misc-*,-misc-no-recursion,-misc-unused-parameters,-misc-non-private-member-variables-in-classes' --- > Checks: 'clang-diagnostic-*,clang-analyzer-*,-*,llvm-*,misc-*,-misc-unused-parameters,-misc-non-private-member-variables-in-classes,-llvm-include-order,-misc-no-recursion' flang/include/flang/Lower/.clang-tidy flang/include/flang/Optimizer/.clang-tidy flang/lib/Lower/.clang-tidy flang/lib/Optimizer/.clang-tidy lld/.clang-tidy lldb/.clang-tidy llvm/tools/split-file/.clang-tidy mlir/.clang-tidy The clang/.clang-tidy change is a no-op, disabling an option that was never enabled. The compiler-rt and flang changes are no-op reorderings of the same flags. (side note, the .clang-tidy file in parallel-libs is broken and crashes clang-tidy because it uses "lowerCase" as the style instead of "lower_case" - so I'll deal with that separately) Differential Revision: https://reviews.llvm.org/D103842 | 4 年前 | |
Update .gitignore to ignore hidden MacOSX Finder droppings llvm-svn: 213195 | 11 年前 | |
[cmake] Don't export LLVM_TOOLS_INSTALL_DIR anymore First of all, LLVM_TOOLS_INSTALL_DIR put there breaks our NixOS builds, because LLVM_TOOLS_INSTALL_DIR defined the same as CMAKE_INSTALL_BINDIR becomes an *absolute* path, and then when downstream projects try to install there too this breaks because our builds always install to fresh directories for isolation's sake. Second of all, note that LLVM_TOOLS_INSTALL_DIR stands out against the other specially crafted LLVM_CONFIG_* variables substituted in llvm/cmake/modules/LLVMConfig.cmake.in. @beanz added it in d0e1c2a550ef348aae036d0fe78cab6f038c420c to fix a dangling reference in AddLLVM, but I am suspicious of how this variable doesn't follow the pattern. Those other ones are carefully made to be build-time vs install-time variables depending on which LLVMConfig.cmake is being generated, are carefully made relative as appropriate, etc. etc. For my NixOS use-case they are also fine because they are never used as downstream install variables, only for reading not writing. To avoid the problems I face, and restore symmetry, I deleted the exported and arranged to have many ${project}_TOOLS_INSTALL_DIRs. AddLLVM now instead expects each project to define its own, and they do so based on CMAKE_INSTALL_BINDIR. LLVMConfig still exports LLVM_TOOLS_BINARY_DIR which is the location for the tools defined in the usual way, matching the other remaining exported variables. For the AddLLVM changes, I tried to copy the existing pattern of internal vs non-internal or for LLVM vs for downstream function/macro names, but it would good to confirm I did that correctly. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D117977 | 3 年前 | |
Add code owners of new MachO port | 5 年前 | |
Fix typos throughout the license files that somehow I and my reviewers all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended legacy anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. llvm-svn: 351731 | 7 年前 | |
[doc] Place sha256 in lld/README.md into backticks Reviewed By: smeenai Differential Revision: https://reviews.llvm.org/D93984 | 5 年前 |
LLVM Linker (lld)
This directory and its subdirectories contain source code for the LLVM Linker, a modular cross platform linker which is built as part of the LLVM compiler infrastructure project.
lld is open source software. You may freely distribute it under the terms of the license agreement found in LICENSE.txt.
Benchmarking
In order to make sure various developers can evaluate patches over the same tests, we create a collection of self contained programs.
It is hosted at https://s3-us-west-2.amazonaws.com/linker-tests/lld-speed-test.tar.xz
The current sha256 is 10eec685463d5a8bbf08d77f4ca96282161d396c65bd97dc99dbde644a31610f.