| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[LLD] [MachO] Fix GCC build warnings This fixes the following warnings produced by GCC 9: ../tools/lld/MachO/Arch/ARM64.cpp: In member function ‘void {anonymous}::OptimizationHintContext::applyAdrpLdr(const lld::macho::OptimizationHint&)’: ../tools/lld/MachO/Arch/ARM64.cpp:448:18: warning: comparison of integer expressions of different signedness: ‘int64_t’ {aka ‘long int’} and ‘uint64_t’ {aka ‘long unsigned int’} [-Wsign-compare] 448 | if (ldr.offset != (rel1->referentVA & 0xfff)) | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../tools/lld/MachO/UnwindInfoSection.cpp: In function ‘bool canFoldEncoding(compact_unwind_encoding_t)’: ../tools/lld/MachO/UnwindInfoSection.cpp:404:44: warning: comparison between ‘enum<unnamed>’ and ‘enum<unnamed>’ [-Wenum-compare] 404 | static_assert(UNWIND_X86_64_MODE_MASK == UNWIND_X86_MODE_MASK, ""); | ^~~~~~~~~~~~~~~~~~~~ ../tools/lld/MachO/UnwindInfoSection.cpp:405:49: warning: comparison between ‘enum<unnamed>’ and ‘enum<unnamed>’ [-Wenum-compare] 405 | static_assert(UNWIND_X86_64_MODE_STACK_IND == UNWIND_X86_MODE_STACK_IND, ""); | ^~~~~~~~~~~~~~~~~~~~~~~~~ Differential Revision: https://reviews.llvm.org/D130970 (cherry picked from commit 59c6f418fa3c5d6f5c8b75ebd817be8113de7931) | 3 年前 | |
[lld-macho][reland] Initial support for EH Frames This reverts commit 942f4e3a7cc9a9f8b2654817cff12907d1276031. The additional change required to avoid the assertion errors seen previously is: --- a/lld/MachO/ICF.cpp +++ b/lld/MachO/ICF.cpp @@ -443,7 +443,9 @@ void macho::foldIdenticalSections() { /*relocVA=*/0); isec->data = copy; } - } else { + } else if (!isEhFrameSection(isec)) { + // EH frames are gathered as hashables from unwindEntry above; give a + // unique ID to everything else. isec->icfEqClass[0] = ++icfUniqueID; } } Differential Revision: https://reviews.llvm.org/D123435 | 3 年前 | |
Replace to_hexString by touhexstr [NFC] LLVM had 2 methods to convert a number to an hexa string, this remove one of them. Differential Revision: https://reviews.llvm.org/D127958 | 3 年前 | |
[lld-macho][nfc] Give non-text ConcatOutputSections order-independent finalization This diff is motivated by my work to add proper DWARF unwind support. As detailed in PR50956 functions that need DWARF unwind need to have compact unwind entries synthesized for them. These CU entries encode an offset within __eh_frame that points to the corresponding DWARF FDE. In order to encode this offset during UnwindInfoSectionImpl::finalize(), we need to first assign values to InputSection::outSecOff for each __eh_frame subsection. But __eh_frame is ordered after __unwind_info (according to ld64 at least), which puts us in a bit of a bind: outSecOff gets assigned during finalization, but __eh_frame is being finalized after __unwind_info. But it occurred to me that there's no real need for most ConcatOutputSections to be finalized sequentially. It's only necessary for text-containing ConcatOutputSections that may contain branch relocs which may need thunks. ConcatOutputSections containing other types of data can be finalized in any order. This diff moves the finalization logic for non-text sections into a separate finalizeContents() method. This method is called before section address assignment & unwind info finalization takes place. In theory we could call these finalizeContents() methods in parallel, but in practice it seems to be faster to do it all on the main thread. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D123279 | 4 年前 | |
feat: support mac lto Signed-off-by: jinbohang <jinbohang1@huawei.com> | 13 天前 | |
feat: support mac lto Signed-off-by: jinbohang <jinbohang1@huawei.com> | 13 天前 | |
[lld/mac] For catalyst outputs, tolerate implicitly linking against mac-only tbd files Before this, clang empty.cc -target x86_64-apple-ios13.1-macabi \ -framework CoreServices -fuse-ld=lld would error out with ld64.lld: error: path/to/MacOSX.sdk/System/Library/Frameworks/ CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/ Versions/A/CarbonCore.tbd( /System/Library/Frameworks/ CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/ Versions/A/CarbonCore) is incompatible with x86_64 (macCatalyst) Now it works, like with ld64. Differential Revision: https://reviews.llvm.org/D124336 | 4 年前 | |
[lld/mac] Add support for $ld$previous symbols with explicit symbol name A symbol $ld$previous$/Another$1.2.3$1$3.0$14.0$_xxx$ means "pretend symbol _xxx is in dylib /Another with version 1.2.3 if the deployment target is between 3.0 and 14.0 and we're targeting platform 1 (ie macOS)". This means dylibs can now inject synthetic dylibs into the link, so DylibFile needs to grow a 3rd constructor. The only other interesting thing is that such an injected dylib counts as a use of the original dylib. This patch gets this mostly right (if _only_ $ld$previous symbols are used from a dylib, we don't add a dep on the dylib itself, matching ld64), but one case where we don't match ld64 yet is that ld64 even omits the original dylib when linking it with -needed-l. Lld currently still adds a load command for the original dylib in that case. (That's for a future patch.) Fixes #56074. Differential Revision: https://reviews.llvm.org/D130725 (cherry picked from commit 241f0e8b76d544a4a07a7f775b8421632539be19) | 3 年前 | |
Reland "[lld-macho] Show source information for undefined references" The error used to look like this: ld64.lld: error: undefined symbol: _foo >>> referenced by /path/to/bar.o:(symbol _baz+0x4) If DWARF line information is available, we now show where in the source the references are coming from: ld64.lld: error: unreferenced symbol: _foo >>> referenced by: bar.cpp:42 (/path/to/bar.cpp:42) >>> /path/to/bar.o:(symbol _baz+0x4) The reland is identical to the first time this landed. The fix was in D128294. This reverts commit 0cc7ad417585b3185c32e395cc5e6cf082a347af. Differential Revision: https://reviews.llvm.org/D128184 | 3 年前 | |
Reland "[lld-macho] Show source information for undefined references" The error used to look like this: ld64.lld: error: undefined symbol: _foo >>> referenced by /path/to/bar.o:(symbol _baz+0x4) If DWARF line information is available, we now show where in the source the references are coming from: ld64.lld: error: unreferenced symbol: _foo >>> referenced by: bar.cpp:42 (/path/to/bar.cpp:42) >>> /path/to/bar.o:(symbol _baz+0x4) The reland is identical to the first time this landed. The fix was in D128294. This reverts commit 0cc7ad417585b3185c32e395cc5e6cf082a347af. Differential Revision: https://reviews.llvm.org/D128184 | 3 年前 | |
[lld-macho] Support EH frame pointer encodings that use sdata4 Previously we only supporting using the system pointer size (aka the absptr encoding) because llvm-mc's CFI directives always generate EH frames with that encoding. But libffi uses 4-byte-encoded, hand-rolled EH frames, so this patch adds support for it. Fixes #56576. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D130804 (cherry picked from commit 6c9f6812523a706c11a12e6cb4119b0cf67bbb21) | 3 年前 | |
[lld-macho] Support EH frame pointer encodings that use sdata4 Previously we only supporting using the system pointer size (aka the absptr encoding) because llvm-mc's CFI directives always generate EH frames with that encoding. But libffi uses 4-byte-encoded, hand-rolled EH frames, so this patch adds support for it. Fixes #56576. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D130804 (cherry picked from commit 6c9f6812523a706c11a12e6cb4119b0cf67bbb21) | 3 年前 | |
Reland "[lld-macho] Avoid using bump-alloc in TrieBuider"" This reverts commit ee7a286cd3e4364d2f7d5b6ba4b8a6fc0d524854. | 4 年前 | |
Reland "[lld-macho] Avoid using bump-alloc in TrieBuider"" This reverts commit ee7a286cd3e4364d2f7d5b6ba4b8a6fc0d524854. | 4 年前 | |
[lld-macho] Fold cfstrings with --deduplicate-literals Similar to cstrings ld64 always deduplicates cfstrings. This was already being done when enabling ICF, but for debug builds you may want to flip this on if you cannot eliminate your instances of this, so this change makes --deduplicate-literals also apply to cfstrings. Differential Revision: https://reviews.llvm.org/D130134 | 3 年前 | |
[lld-macho] Fold cfstrings with --deduplicate-literals Similar to cstrings ld64 always deduplicates cfstrings. This was already being done when enabling ICF, but for debug builds you may want to flip this on if you cannot eliminate your instances of this, so this change makes --deduplicate-literals also apply to cfstrings. Differential Revision: https://reviews.llvm.org/D130134 | 3 年前 | |
fix: allow linking with ABI compatible architectures for xcode 26.4 Signed-off-by: neilliuistaken <liujiajie12@huawei.com> | 2 个月前 | |
[lld/mac] Add support for $ld$previous symbols with explicit symbol name A symbol $ld$previous$/Another$1.2.3$1$3.0$14.0$_xxx$ means "pretend symbol _xxx is in dylib /Another with version 1.2.3 if the deployment target is between 3.0 and 14.0 and we're targeting platform 1 (ie macOS)". This means dylibs can now inject synthetic dylibs into the link, so DylibFile needs to grow a 3rd constructor. The only other interesting thing is that such an injected dylib counts as a use of the original dylib. This patch gets this mostly right (if _only_ $ld$previous symbols are used from a dylib, we don't add a dep on the dylib itself, matching ld64), but one case where we don't match ld64 yet is that ld64 even omits the original dylib when linking it with -needed-l. Lld currently still adds a load command for the original dylib in that case. (That's for a future patch.) Fixes #56074. Differential Revision: https://reviews.llvm.org/D130725 (cherry picked from commit 241f0e8b76d544a4a07a7f775b8421632539be19) | 3 年前 | |
[lld-macho] Demangle location name in undefined symbol diagnostics If the -demangle flag is passed to lld, symbol names will now be demangled in the "referenced by:" message in addition to the referenced symbol's name, which was already demangled before this change. Differential Revision: https://reviews.llvm.org/D130490 | 3 年前 | |
[lld-macho] Fold __objc_imageinfo sections Previously, we treated it as a regular ConcatInputSection. However, ld64 actually parses its contents and uses that to synthesize a single image info struct, generating one 8-byte section instead of 8 * number of object files with ObjC code. I'm not entirely sure what impact this section has on the runtime, so I just tried to follow ld64's semantics as closely as possible in this diff. My main motivation though was to reduce binary size. No significant perf change on chromium_framework on my 16-core Mac Pro: base diff difference (95% CI) sys_time 1.764 ± 0.062 1.748 ± 0.032 [ -2.4% .. +0.5%] user_time 5.112 ± 0.104 5.106 ± 0.046 [ -0.9% .. +0.7%] wall_time 6.111 ± 0.184 6.085 ± 0.076 [ -1.6% .. +0.8%] samples 30 32 Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D130125 | 3 年前 | |
feat: support mac lto Signed-off-by: jinbohang <jinbohang1@huawei.com> | 13 天前 | |
[lld-macho] Add LTO cache support This adds support for the lld-only --thinlto-cache-policy option, as well as implementations for ld64's -cache_path_lto, -prune_interval_lto, -prune_after_lto, and -max_relative_cache_size_lto. Test is adapted from lld/test/ELF/lto/cache.ll Differential Revision: https://reviews.llvm.org/D105922 | 4 年前 | |
[lld-macho] Add support for arm64_32 From what I can tell, it's pretty similar to arm64. The two main differences are: 1. No 64-bit relocations 2. Stub code writes to 32-bit registers instead of 64-bit Plus of course the various on-disk structures like segment_command are using the 32-bit instead of the 64-bit variants. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99822 | 5 年前 | |
Rename parallelForEachN to just parallelFor Patch created by running: rg -l parallelForEachN | xargs sed -i '' -c 's/parallelForEachN/parallelFor/' No behavior change. Differential Revision: https://reviews.llvm.org/D128140 | 3 年前 | |
[lld-macho] implement options -map Implement command-line options -map Reviewed By: int3, #lld-macho Differential Revision: https://reviews.llvm.org/D98323 | 5 年前 | |
[lld-macho][nfc] Run clang-format on lld/MachO/*.{h,cpp} - fixed inconsistent indents and spaces - prevent extraneous formatting changes in other patches Differential Revision: https://reviews.llvm.org/D126262 | 4 年前 | |
[lld/mac] Implement -dead_strip Also adds support for live_support sections, no_dead_strip sections, .no_dead_strip symbols. Chromium Framework 345MB unstripped -> 250MB stripped (vs 290MB unstripped -> 236M stripped with ld64). Doing dead stripping is a bit faster than not, because so much less data needs to be processed: % ministat lld_* x lld_nostrip.txt + lld_strip.txt N Min Max Median Avg Stddev x 10 3.929414 4.07692 4.0269079 4.0089678 0.044214794 + 10 3.8129408 3.9025559 3.8670411 3.8642573 0.024779651 Difference at 95.0% confidence -0.144711 +/- 0.0336749 -3.60967% +/- 0.839989% (Student's t, pooled s = 0.0358398) This interacts with many parts of the linker. I tried to add test coverage for all added isLive() checks, so that some test will fail if any of them is removed. I checked that the test expectations for the most part match ld64's behavior (except for live-support-iterations.s, see the comment in the test). Interacts with: - debug info - export tries - import opcodes - flags like -exported_symbol(s_list) - -U / dynamic_lookup - mod_init_funcs, mod_term_funcs - weak symbol handling - unwind info - stubs - map files - -sectcreate - undefined, dylib, common, defined (both absolute and normal) symbols It's possible it interacts with more features I didn't think of, of course. I also did some manual testing: - check-llvm check-clang check-lld work with lld with this patch as host linker and -dead_strip enabled - Chromium still starts - Chromium's base_unittests still pass, including unwind tests Implemenation-wise, this is InputSection-based, so it'll work for object files with .subsections_via_symbols (which includes all object files generated by clang). I first based this on the COFF implementation, but later realized that things are more similar to ELF. I think it'd be good to refactor MarkLive.cpp to look more like the ELF part at some point, but I'd like to get a working state checked in first. Mechanical parts: - Rename canOmitFromOutput to wasCoalesced (no behavior change) since it really is for weak coalesced symbols - Add noDeadStrip to Defined, corresponding to N_NO_DEAD_STRIP (.no_dead_strip in asm) Fixes PR49276. Differential Revision: https://reviews.llvm.org/D103324 | 4 年前 | |
[lld/macho] Fixes the -ObjC flag When checking the segment name for Swift symbols, we should be checking that they start with __swift instead of checking for equality Fixes the issue https://github.com/llvm/llvm-project/issues/55355 Reviewed By: #lld-macho, keith, thevinster Differential Revision: https://reviews.llvm.org/D125250 | 4 年前 | |
[lld-macho] Implement -ObjC It's roughly like -force_load with some filtering. Differential Revision: https://reviews.llvm.org/D86181 | 5 年前 | |
fix: delete useless warning Signed-off-by: jinbohang <jinbohang1@huawei.com> | 10 天前 | |
[lld-macho][nfc] Run clang-format on lld/MachO/*.{h,cpp} - fixed inconsistent indents and spaces - prevent extraneous formatting changes in other patches Differential Revision: https://reviews.llvm.org/D126262 | 4 年前 | |
[lld-macho][nfc] Comments and style fixes Added some comments (particularly around finalize() and finalizeContents()) as well as doing some rephrasing / grammar fixes for existing comments. Also did some minor style fixups, such as by putting methods together in a class definition and having fields of similar types next to each other. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D118714 | 4 年前 | |
feat: 930 opensource Signed-off-by: wzy_00889928 <1322947566@qq.com> | 7 个月前 | |
feat: 930 opensource Signed-off-by: wzy_00889928 <1322947566@qq.com> | 7 个月前 | |
[lld-macho] Have relocation address included in range-check error message This makes it easier to debug those errors. See e.g. https://github.com/llvm/llvm-project/issues/52767#issuecomment-1028713943 We take the approach of 'reverse-engineering' the InputSection from the output buffer offset. This provides for a cleaner Target API, and is similar to LLD-ELF's implementation of getErrorPlace(). Reviewed By: #lld-macho, Roger Differential Revision: https://reviews.llvm.org/D118903 | 4 年前 | |
[lld-macho] Initial support for Linker Optimization Hints Linker optimization hints mark a sequence of instructions used for synthesizing an address, like ADRP+ADD. If the referenced symbol ends up close enough, it can be replaced by a faster sequence of instructions like ADR+NOP. This commit adds support for 2 of the 7 defined ARM64 optimization hints: - LOH_ARM64_ADRP_ADD, which transforms a pair of ADRP+ADD into ADR+NOP if the referenced address is within +/- 1 MiB - LOH_ARM64_ADRP_ADRP, which transforms two ADRP instructions into ADR+NOP if they reference the same page These two kinds already cover more than 50% of all LOHs in chromium_framework. Differential Review: https://reviews.llvm.org/D128093 | 3 年前 | |
Use value instead of getValue (NFC) | 3 年前 | |
[lld-macho][NFC] Encapsulate symbol priority implementation. Just some code clean up. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D122752 | 4 年前 | |
[lld-macho] Add support for -alias This creates a symbol alias similar to --defsym in the elf linker. This is used by swiftpm for all executables, so it's useful to support. This doesn't implement -alias_list but that could be done pretty easily as needed. Differential Revision: https://reviews.llvm.org/D129938 | 3 年前 | |
[lld-macho] Add support for -alias This creates a symbol alias similar to --defsym in the elf linker. This is used by swiftpm for all executables, so it's useful to support. This doesn't implement -alias_list but that could be done pretty easily as needed. Differential Revision: https://reviews.llvm.org/D129938 | 3 年前 | |
[lld-macho] Use source information in duplicate symbol errors Similarly to how undefined symbol diagnostics were changed in D128184, we now show where in the source file duplicate symbols are defined at: ld64.lld: error: duplicate symbol: _foo >> defined in bar.c:42 >> /path/to/bar.o >> defined in baz.c:1 >> /path/to/libbaz.a(baz.o) For objects that don't contain DWARF data, the format is unchanged. A slight difference to undefined symbol diagnostics is that we don't print the name of the symbol on the third line, as it's already contained on the first line. Differential Revision: https://reviews.llvm.org/D128425 | 3 年前 | |
[lld-macho] Use source information in duplicate symbol errors Similarly to how undefined symbol diagnostics were changed in D128184, we now show where in the source file duplicate symbols are defined at: ld64.lld: error: duplicate symbol: _foo >> defined in bar.c:42 >> /path/to/bar.o >> defined in baz.c:1 >> /path/to/libbaz.a(baz.o) For objects that don't contain DWARF data, the format is unchanged. A slight difference to undefined symbol diagnostics is that we don't print the name of the symbol on the third line, as it's already contained on the first line. Differential Revision: https://reviews.llvm.org/D128425 | 3 年前 | |
[lld-macho][nfc] Reduce nesting of code added in D130125 | 3 年前 | |
Remove redundaunt override specifiers (NFC) Identified with modernize-use-override. | 3 年前 | |
[lld-macho][nfc] Create Relocations.{h,cpp} for relocation-specific code This more closely mirrors the structure of lld-ELF. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D98384 | 5 年前 | |
[lld-macho] Devirtualize TargetInfo::getRelocAttrs This method is called on each relocation when parsing input files, so the overhead of using virtual functions ends up being quite large. We now have a single non-virtual method, which reads from the appropriate array of relocation attributes set in the TargetInfo constructor. This change results in a modest 2.3% reduction in link time for chromium_framework measured on an x86-64 VPS, and 0.7% on an arm64 Mac. N Min Max Median Avg Stddev x 10 11.869417 12.032609 11.935041 11.938268 0.045802324 + 10 11.581526 11.785265 11.649885 11.659507 0.054634834 Difference at 95.0% confidence -0.278761 +/- 0.0473673 -2.33502% +/- 0.396768% (Student's t, pooled s = 0.0504124) Differential Revision: https://reviews.llvm.org/D130000 | 3 年前 | |
[lld-macho] Canonicalize personality pointers in EH frames We already do this for personality pointers referenced from compact unwind entries; this patch extends that behavior to personalities referenced via EH frames as well. This reduces the number of distinct personalities we need in the final binary, and helps us avoid hitting the "too many personalities" error. I renamed UnwindInfoSection::prepareRelocations() to simply prepare since we now do some non-reloc-specific stuff within. Fixes #58277. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D135728 (cherry picked from commit 7b45dfc6811a52ff4e9a6054dc276d70d77fddaf) | 3 年前 | |
[lld-macho] Canonicalize personality pointers in EH frames We already do this for personality pointers referenced from compact unwind entries; this patch extends that behavior to personalities referenced via EH frames as well. This reduces the number of distinct personalities we need in the final binary, and helps us avoid hitting the "too many personalities" error. I renamed UnwindInfoSection::prepareRelocations() to simply prepare since we now do some non-reloc-specific stuff within. Fixes #58277. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D135728 (cherry picked from commit 7b45dfc6811a52ff4e9a6054dc276d70d77fddaf) | 3 年前 | |
feat: 930 opensource Signed-off-by: wzy_00889928 <1322947566@qq.com> | 7 个月前 | |
[MachO] Properly reset global state We need to reset global state between runs, similar to the other ports. There's some file-static state which needs to be reset as well and we need to add some new helpers for that. With this change, most LLD Mach-O tests pass with LLD_IN_TEST=2 (which runs the linker twice on each test). Some tests will be fixed by the remainder of this stack, and the rest are fundamentally incompatible with that mode (e.g. they intentionally throw fatal errors). Fixes PR52070. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D112878 | 4 年前 | |
[lld-macho][nfc] Fix formatting in ld64-vs-lld.rst | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 13 天前 | ||
| 13 天前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 个月前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 13 天前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 10 天前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 7 个月前 | ||
| 7 个月前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 7 个月前 | ||
| 4 年前 | ||
| 4 年前 |