| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lld-macho] Fix segfault when handling LTO + object file weak defs which occurs when there are EH frames present in the object file's weak def. Reviewed By: abrachet Differential Revision: https://reviews.llvm.org/D130409 | 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][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 年前 | |
[lld-macho][nfc] Clean up tests * Remove unnecessary rm -rf %ts * Have lc-linker-option.ll use the right comment marker | 5 年前 | |
[lld-macho][nfc] Extend abs-symbol.s to test for local absolute symbols Addresses an old TODO. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D100082 | 5 年前 | |
[lld-macho] Support -add_ast_path Swift builds seem to use it. All it requires is emitting the corresponding paths as STABS. Fixes llvm.org/PR49385. Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D100076 | 5 年前 | |
Add MachO signature verification test Add a test to ensure that MachO files including a LC_CODE_SIGNATURE load command produced by lld are signed correctly. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D109840 | 4 年前 | |
[lld-macho][nfc] Centralize usages of ld64.lld in tests We have a mix of substituted lld ( %lld) and hard-coded lld (ld64.lld) commands. When testing with different versions of LLD, this would require going into every place where lld is hard-coded and changing that. If we centralize it, this'll only require us to modify it in only one place and will make it easy to run the same test suite. Plus, this will make it be consistent with how we write other tests. Reviewed By: #lld-macho, int3, oontvoo Differential Revision: https://reviews.llvm.org/D119394 | 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/mac] Fix application-extension.s failure after 8e8701abca3d4 The test accidentally tested something else that makes lld fail with a different (correct-looking) error that wasn't the one the test tries to test for. (The test case before this change makes ld64 hang in an infinite loop.) | 4 年前 | |
[lld/mac] Implement -arch_multiple This is the other flag clang passes when calling clang with two -arch flags (which means with this, clang -arch x86_64 -arch arm64 -fuse-ld=lld ... now no longer prints any warnings \o/). Since clang calls the linker several times in that setup, it's not clear to the user from which invocation the errors are. The flag's help text is Specifies that the linker should augment error and warning messages with the architecture name. In ld64, the only effect of the flag is that undefined symbols are prefaced with Undefined symbols for architecture x86_64: instead of the usual "Undefined symbols:". So for now, let's add this only to undefined symbol errors too. That's probably the most common linker diagnostic. Another idea would be to prefix errors and warnings with "ld64.lld(x86_64):" instead of the usual "ld64.lld:", but I'm not sure if people would misunderstand that as a comment about the arch of ld itself. But open to suggestions on what effect this flag should have :) And we don't have to get it perfect now, we can iterate on it. Differential Revision: https://reviews.llvm.org/D105450 | 4 年前 | |
[lld-macho] Always include custom syslibroot when running tests This greatly reduces the amount of boilerplate in our tests. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D87960 | 5 年前 | |
[lld-macho][nfc] Rename some tests for consistency Now all the tests that cover symbol resolution / precedence have "resolution" in their filename. I also added a couple of extra comments. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D120938 | 4 年前 | |
[lld-macho] Implement -noall_load This flag is the default, so in ld64 it is not implemented, but it can be useful to negate previous -all_load arguments. Specifically if your build system has some global linker flags, that you may want to negate for specific links. We use something like this today to make sure some C++ symbols are automatically discovered for all links, which passing -all_load hides. Differential Revision: https://reviews.llvm.org/D117629 | 4 年前 | |
[lld-macho] Preliminary support for ARM_RELOC_BR24 ARM_RELOC_BR24 is used for BL/BLX instructions from within ARM (i.e. not Thumb) code. This diff just handles the basic case: branches from ARM to ARM, or from ARM to Thumb where no shimming is required. (See comments in ARM.cpp for why shims are required.) Note: I will likely be deprioritizing ARM work for the near future to focus on other parts of LLD. Apologies for the half-done state of this; I'm just trying to wrap up what I've already worked on. Reviewed By: #lld-macho, alexshap Differential Revision: https://reviews.llvm.org/D101814 | 5 年前 | |
[lld-macho] Handle user-provided dtrace symbols to avoid linking failure This fixes https://github.com/llvm/llvm-project/issues/56238. ld64.lld currently does not generate __dof section in Mach-O, and -no_dtrace_dof option is on by default. However when there are user-defined dtrace symbols, ld64.lld will treat them as undefined symbols, which causes the linking to fail because lld cannot find their definitions. This patch allows ld64.lld to rewrite the instructions calling dtrace symbols to instructions like nop as what ld64 does; therefore, when encountered with user-provided dtrace probes, the linking can still succeed. I'm not sure whether support for dtrace is expected in lld, so for now I didn't add codes to make lld emit __dof section like ld64, and only made it possible to link with dtrace symbols provided. If this feature is needed, I can add that part in Dtrace.cpp & Dtrace.h. Reviewed By: int3, #lld-macho Differential Revision: https://reviews.llvm.org/D129062 | 3 年前 | |
[lld-macho] Handle user-provided dtrace symbols to avoid linking failure This fixes https://github.com/llvm/llvm-project/issues/56238. ld64.lld currently does not generate __dof section in Mach-O, and -no_dtrace_dof option is on by default. However when there are user-defined dtrace symbols, ld64.lld will treat them as undefined symbols, which causes the linking to fail because lld cannot find their definitions. This patch allows ld64.lld to rewrite the instructions calling dtrace symbols to instructions like nop as what ld64 does; therefore, when encountered with user-provided dtrace probes, the linking can still succeed. I'm not sure whether support for dtrace is expected in lld, so for now I didn't add codes to make lld emit __dof section like ld64, and only made it possible to link with dtrace symbols provided. If this feature is needed, I can add that part in Dtrace.cpp & Dtrace.h. Reviewed By: int3, #lld-macho Differential Revision: https://reviews.llvm.org/D129062 | 3 年前 | |
[llvm-objdump] Improve newline consistency between different pieces of information When dumping multiple pieces of information (e.g. --all-headers), there is sometimes no separator between two pieces. This patch uses the "\nheader:\n" style, which generally improves compatibility with GNU objdump. Note: objdump -t/-T does not add a newline before "SYMBOL TABLE:" and "DYNAMIC SYMBOL TABLE:". We add a newline to be consistent with other information. objdump -d prints two empty lines before the first 'Disassembly of section'. We print just one with this patch. Differential Revision: https://reviews.llvm.org/D101796 | 5 年前 | |
[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 年前 | |
[lld-macho] Handle user-provided dtrace symbols to avoid linking failure This fixes https://github.com/llvm/llvm-project/issues/56238. ld64.lld currently does not generate __dof section in Mach-O, and -no_dtrace_dof option is on by default. However when there are user-defined dtrace symbols, ld64.lld will treat them as undefined symbols, which causes the linking to fail because lld cannot find their definitions. This patch allows ld64.lld to rewrite the instructions calling dtrace symbols to instructions like nop as what ld64 does; therefore, when encountered with user-provided dtrace probes, the linking can still succeed. I'm not sure whether support for dtrace is expected in lld, so for now I didn't add codes to make lld emit __dof section like ld64, and only made it possible to link with dtrace symbols provided. If this feature is needed, I can add that part in Dtrace.cpp & Dtrace.h. Reviewed By: int3, #lld-macho Differential Revision: https://reviews.llvm.org/D129062 | 3 年前 | |
[llvm-objdump] Improve newline consistency between different pieces of information When dumping multiple pieces of information (e.g. --all-headers), there is sometimes no separator between two pieces. This patch uses the "\nheader:\n" style, which generally improves compatibility with GNU objdump. Note: objdump -t/-T does not add a newline before "SYMBOL TABLE:" and "DYNAMIC SYMBOL TABLE:". We add a newline to be consistent with other information. objdump -d prints two empty lines before the first 'Disassembly of section'. We print just one with this patch. Differential Revision: https://reviews.llvm.org/D101796 | 5 年前 | |
[lld-macho][nfc] Convert tabs to spaces | 5 年前 | |
[llvm-objdump] Improve newline consistency between different pieces of information When dumping multiple pieces of information (e.g. --all-headers), there is sometimes no separator between two pieces. This patch uses the "\nheader:\n" style, which generally improves compatibility with GNU objdump. Note: objdump -t/-T does not add a newline before "SYMBOL TABLE:" and "DYNAMIC SYMBOL TABLE:". We add a newline to be consistent with other information. objdump -d prints two empty lines before the first 'Disassembly of section'. We print just one with this patch. Differential Revision: https://reviews.llvm.org/D101796 | 5 年前 | |
[lld-macho][nfc] Convert tabs to spaces | 5 年前 | |
[lld-macho][nfc] Add test for ARM64 stubs Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99813 | 5 年前 | |
[lld/mac] Give range extension thunks for local symbols local visibility When two local symbols (think: file-scope static functions, or functions in unnamed namespaces) with the same name in two different translation units both needed thunks, ld64.lld previously created external thunks for both of them. These thunks ended up with the same name, leading to a duplicate symbol error for the thunk symbols. Instead, give thunks for local symbols local visibility. (Hitting this requires a jump to a local symbol from over 128 MiB away. It's unlikely that a single .o file is 128 MiB large, but with ICF you can end up with a situation where the local symbol is ICF'd with a symbol in a separate translation unit. And that can introduce a large enough jump to require a thunk.) Fixes PR54599. Differential Revision: https://reviews.llvm.org/D122624 | 4 年前 | |
[lld/mac] Tweak a few comments Addresses review feedback I had missed on https://reviews.llvm.org/D122624 No behavior change. Differential Revision: https://reviews.llvm.org/D122904 | 4 年前 | |
[lld/mac] Don't assert on -dead_strip + arm64 range extension thunks The assert is harmless and thinks worked fine in builds with asserts enabled, but it's still nice to fix the assert. Differential Revision: https://reviews.llvm.org/D108853 | 4 年前 | |
[lld-macho][nfc] Use %lld-watchos substitution in bind-opcodes.s Previously, we were using a syslibroot that pointed to macos while linking against arch arm64_32, which didn't really make sense. It isn't currently an issue, but will be if we add the -lSystem as part of dealing with https://github.com/llvm/llvm-project/issues/54184. | 4 年前 | |
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the __LLVM segment is directly before __LINKEDIT by checking that fileOff + fileSize == next segment fileOff. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for __LLVM, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the __LINKEDIT segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in __LINKEDIT covers the last byte of the segment, so if we rounded up __LINKEDIT's size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more __LINKEDIT sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848 | 5 年前 | |
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the __LLVM segment is directly before __LINKEDIT by checking that fileOff + fileSize == next segment fileOff. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for __LLVM, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the __LINKEDIT segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in __LINKEDIT covers the last byte of the segment, so if we rounded up __LINKEDIT's size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more __LINKEDIT sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848 | 5 年前 | |
feat: 930 opensource Signed-off-by: wzy_00889928 <1322947566@qq.com> | 8 个月前 | |
[lld-macho] Don't reference entry symbol for non-executables This would cause us to pull in symbols (and code) that should be unused. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D102137 | 5 年前 | |
[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][nfc] Avoid using absolute addresses in cgprofile-icf.s If we fix https://github.com/llvm/llvm-project/issues/54184, the dyld_stub_binder symbol will get included in every output dylib. This would cause the addresses of the other symbols to shift, breaking the test as it currently stands. Let's make the test more flexible. Reviewed By: lgrey Differential Revision: https://reviews.llvm.org/D120940 | 4 年前 | |
[lld-macho] Port CallGraphSort from COFF/ELF Depends on D112160 This adds the new options --call-graph-profile-sort (default), --no-call-graph-profile-sort and --print-symbol-order=. If call graph profile sorting is enabled, reads __LLVM,__cg_profile sections from object files and uses the resulting graph to put callees and callers close to each other in the final binary via the C3 clustering heuristic. Differential Revision: https://reviews.llvm.org/D112164 | 4 年前 | |
[lld-macho] Allow order files and call graph sorting to be used together If both an order file and a call graph profile are present, the edges of the call graph which use symbols present in the order file are not used. All of the symbols in the order file will appear at the beginning of the section just as they do currently. In other words, the highest priority derived from the call graph will be below the lowest priority derived from the order file. Practically, this change renames CallGraphSort.{h,cpp} to SectionPriorities.{h,cpp}, and most order file and call graph profile related code is moved into the new file to reduce duplication. Differential Revision: https://reviews.llvm.org/D117354 | 4 年前 | |
[lld-macho] Port CallGraphSort from COFF/ELF Depends on D112160 This adds the new options --call-graph-profile-sort (default), --no-call-graph-profile-sort and --print-symbol-order=. If call graph profile sorting is enabled, reads __LLVM,__cg_profile sections from object files and uses the resulting graph to put callees and callers close to each other in the final binary via the C3 clustering heuristic. Differential Revision: https://reviews.llvm.org/D112164 | 4 年前 | |
[MachO] Use error instead of fatal for missing -arch fatal should only be used for malformed inputs according to ErrorHandler.h; error is more appropriate for missing arguments, accompanied by a check to bail out early in case of the error. Some tests need to be adjusted accordingly. Makes lld/test/MachO/arch.s pass with LLD_IN_TEST=2. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D112879 | 4 年前 | |
[lld-macho][nfc] Simplify common-symbol-coalescing test | 4 年前 | |
[lld-macho][nfc] Fix test to reflect that symbol attributes don't matter within an archive We had a comment that claimed that defined symbols had priority over common symbols if they occurred in the same archive. In fact, they appear to have equal precedence. Our implementation already does this, so I'm just updating the test comment. Also added a few other test comments along the way for readability. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D106595 | 4 年前 | |
[lld-macho][nfc] Clean up trailing spaces and tabs | 4 年前 | |
fix typos to cycle bots | 4 年前 | |
[MachO] Don't fold compact unwind entries with LSDA Folding them will cause the unwinder to compute the incorrect function start address for the folded entries, which in turn will cause the personality function to interpret the LSDA incorrectly and break exception handling. You can verify the end-to-end flow by creating a simple C++ file: void h(); int main() { h(); } and then linking this file against the liblsda.dylib produced by the test case added here. Before this change, running the resulting program would result in a program termination with an uncaught exception. Afterwards, it works correctly. Reviewed By: #lld-macho, thevinster Differential Revision: https://reviews.llvm.org/D132845 (cherry picked from commit 56bd3185cdd8d79731acd6c75bf41869284a12ed) | 3 年前 | |
[lld/mac] Don't fold UNWIND_X86_64_MODE_STACK_IND unwind entries libunwind uses unwind info to find the function address belonging to the current instruction pointer. libunwind/src/CompactUnwinder.hpp's step functions read functionStart for UNWIND_X86_64_MODE_STACK_IND (and for nothing else), so these encodings need a dedicated entry per function, so that the runtime can get the stacksize off the subq instrunction in the function's prologue. This matches ld64. (CompactUnwinder.hpp from https://opensource.apple.com/source/libunwind/ also reads functionStart in a few more cases if SUPPORT_OLD_BINARIES is set, but it defaults to 0, and ld64 seems to not worry about these additional cases.) Related upstream bug: https://crbug.com/1220175 Differential Revision: https://reviews.llvm.org/D104978 | 4 年前 | |
[lld-macho] Fix symbol relocs handling for LSDAs Similar to D113702, but for the LSDAs. Clang seems to emit all LSDA relocs as section relocs, but ld -r can turn those relocs into symbol ones. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D113721 | 4 年前 | |
[lld-macho] Use fewer indirections in UnwindInfo implementation The previous implementation of UnwindInfoSection materialized all the compact unwind entries & applied their relocations, then parsed the resulting data to generate the final unwind info. This design had some unfortunate conseqeuences: since relocations can only be applied after their referents have had addresses assigned, operations that need to happen before address assignment must contort themselves. (See {D113582} and observe how this diff greatly simplifies it.) Moreover, it made synthesizing new compact unwind entries awkward. Handling PR50956 will require us to do this synthesis, and is the main motivation behind this diff. Previously, instead of generating a new CompactUnwindEntry directly, we would have had to generate a ConcatInputSection with a number of Relocs that would then get "flattened" into a CompactUnwindEntry. This diff introduces an internal representation of CompactUnwindEntry (the former CompactUnwindEntry has been renamed to CompactUnwindLayout). The new CompactUnwindEntry stores references to its personality symbol and LSDA section directly, without the use of Reloc structs. In addition to being easier to work with, this diff also allows us to handle unwind info whose personality symbols are located in sections placed after the __unwind_info. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D123276 | 4 年前 | |
[lld-macho] Align cstrings less conservatively Previously, we aligned every cstring to 16 bytes as a temporary hack to deal with https://github.com/llvm/llvm-project/issues/50135. However, it was highly wasteful in terms of binary size. To recap, in contrast to ELF, which puts strings that need different alignments into different sections, clang's Mach-O backend puts them all in one section. Strings that need to be aligned have the .p2align directive emitted before them, which simply translates into zero padding in the object file. In other words, we have to infer the alignment of the cstrings from their addresses. We differ slightly from ld64 in how we've chosen to align these cstrings. Both LLD and ld64 preserve the number of trailing zeros in each cstring's address in the input object files. When deduplicating identical cstrings, both linkers pick the cstring whose address has more trailing zeros, and preserve the alignment of that address in the final binary. However, ld64 goes a step further and also preserves the offset of the cstring from the last section-aligned address. I.e. if a cstring is at offset 18 in the input, with a section alignment of 16, then both LLD and ld64 will ensure the final address is 2-byte aligned (since 18 == 16 + 2). But ld64 will also ensure that the final address is of the form 16 * k + 2 for some k (which implies 2-byte alignment). Note that ld64's heuristic means that a dedup'ed cstring's final address is dependent on the order of the input object files. E.g. if in addition to the cstring at offset 18 above, we have a duplicate one in another file with a .cstring section alignment of 2 and an offset of zero, then ld64 will pick the cstring from the object file earlier on the command line (since both have the same number of trailing zeros in their address). So the final cstring may either be at some address 16 * k + 2 or at some address 2 * k. I've opted not to follow this behavior primarily for implementation simplicity, and secondarily to save a few more bytes. It's not clear to me that preserving the section alignment + offset is ever necessary, and there are many cases that are clearly redundant. In particular, if an x86_64 object file contains some strings that are accessed via SIMD instructions, then the .cstring section in the object file will be 16-byte-aligned (since SIMD requires its operand addresses to be 16-byte aligned). However, there will typically also be other cstrings in the same file that aren't used via SIMD and don't need this alignment. They will be emitted at some arbitrary address A, but ld64 will treat them as being 16-byte aligned with an offset of 16 % A. I have verified that the two repros in https://github.com/llvm/llvm-project/issues/50135 work well with the new alignment behavior. Fixes https://github.com/llvm/llvm-project/issues/54036. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D121342 | 4 年前 | |
[lld-macho] Align cstrings less conservatively Previously, we aligned every cstring to 16 bytes as a temporary hack to deal with https://github.com/llvm/llvm-project/issues/50135. However, it was highly wasteful in terms of binary size. To recap, in contrast to ELF, which puts strings that need different alignments into different sections, clang's Mach-O backend puts them all in one section. Strings that need to be aligned have the .p2align directive emitted before them, which simply translates into zero padding in the object file. In other words, we have to infer the alignment of the cstrings from their addresses. We differ slightly from ld64 in how we've chosen to align these cstrings. Both LLD and ld64 preserve the number of trailing zeros in each cstring's address in the input object files. When deduplicating identical cstrings, both linkers pick the cstring whose address has more trailing zeros, and preserve the alignment of that address in the final binary. However, ld64 goes a step further and also preserves the offset of the cstring from the last section-aligned address. I.e. if a cstring is at offset 18 in the input, with a section alignment of 16, then both LLD and ld64 will ensure the final address is 2-byte aligned (since 18 == 16 + 2). But ld64 will also ensure that the final address is of the form 16 * k + 2 for some k (which implies 2-byte alignment). Note that ld64's heuristic means that a dedup'ed cstring's final address is dependent on the order of the input object files. E.g. if in addition to the cstring at offset 18 above, we have a duplicate one in another file with a .cstring section alignment of 2 and an offset of zero, then ld64 will pick the cstring from the object file earlier on the command line (since both have the same number of trailing zeros in their address). So the final cstring may either be at some address 16 * k + 2 or at some address 2 * k. I've opted not to follow this behavior primarily for implementation simplicity, and secondarily to save a few more bytes. It's not clear to me that preserving the section alignment + offset is ever necessary, and there are many cases that are clearly redundant. In particular, if an x86_64 object file contains some strings that are accessed via SIMD instructions, then the .cstring section in the object file will be 16-byte-aligned (since SIMD requires its operand addresses to be 16-byte aligned). However, there will typically also be other cstrings in the same file that aren't used via SIMD and don't need this alignment. They will be emitted at some arbitrary address A, but ld64 will treat them as being 16-byte aligned with an offset of 16 % A. I have verified that the two repros in https://github.com/llvm/llvm-project/issues/50135 work well with the new alignment behavior. Fixes https://github.com/llvm/llvm-project/issues/54036. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D121342 | 4 年前 | |
[lld/mac] Support -data_in_code_info, -function_starts flags These are on by default, but there's also an explicit flag for them. Differential Revision: https://reviews.llvm.org/D104543 | 4 年前 | |
[lld-macho] Preserve alignment for non-deduplicated cstrings Fixes PR50637. Downstream bug: https://crbug.com/1218958 Currently, we split __cstring along symbol boundaries with .subsections_via_symbols when not deduplicating, and along null bytes when deduplicating. This change splits along null bytes unconditionally, and preserves original alignment in the non- deduplicated case. Removing subsections-section-relocs.s because with this change, __cstring is never reordered based on the order file. Differential Revision: https://reviews.llvm.org/D104919 | 4 年前 | |
[lld/mac] Add a test for -reexport_library + -dead_strip_dylibs Our behavior here already matched ld64, now we have a test for it. (ld64 even strips the library here if you also pass -needed_library bar.dylib. That seems wrong to me, and lld honors needed_library in that case.) Differential Revision: https://reviews.llvm.org/D103812 | 4 年前 | |
[lld][Macho] Include dead-stripped symbols in mapfile ld64 outputs dead stripped symbols when using the -dead-strip flag. This change mimics that behavior for lld. ld64's -dead_strip flag outputs: $ ld -map map basics.o -o out -dead_strip -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -lSystem $ cat map # Path: out # Arch: x86_64 # Object files: [ 0] linker synthesized [ 1] basics.o # Sections: # Address Size Segment Section 0x100003F97 0x00000021 __TEXT __text 0x100003FB8 0x00000048 __TEXT __unwind_info 0x100004000 0x00000008 __DATA_CONST __got 0x100008000 0x00000010 __DATA __ref_section 0x100008010 0x00000001 __DATA __common # Symbols: # Address Size File Name 0x100003F97 0x00000006 [ 1] _ref_local 0x100003F9D 0x00000001 [ 1] _ref_private_extern 0x100003F9E 0x0000000C [ 1] _main 0x100003FAA 0x00000006 [ 1] _no_dead_strip_globl 0x100003FB0 0x00000001 [ 1] _ref_from_no_dead_strip_globl 0x100003FB1 0x00000006 [ 1] _no_dead_strip_local 0x100003FB7 0x00000001 [ 1] _ref_from_no_dead_strip_local 0x100003FB8 0x00000048 [ 0] compact unwind info 0x100004000 0x00000008 [ 0] non-lazy-pointer-to-local: _ref_com 0x100008000 0x00000008 [ 1] _ref_data 0x100008008 0x00000008 [ 1] l_ref_data 0x100008010 0x00000001 [ 1] _ref_com # Dead Stripped Symbols: # Size File Name <<dead>> 0x00000006 [ 1] _unref_extern <<dead>> 0x00000001 [ 1] _unref_local <<dead>> 0x00000007 [ 1] _unref_private_extern <<dead>> 0x00000001 [ 1] _ref_private_extern_u <<dead>> 0x00000008 [ 1] _unref_data <<dead>> 0x00000008 [ 1] l_unref_data <<dead>> 0x00000001 [ 1] _unref_com Reviewed By: int3, #lld-macho, thevinster Differential Revision: https://reviews.llvm.org/D114737 | 4 年前 | |
[nfc][lld-macho] Follow up fixes to bd9e46815d73e4236c207bad8b5c54e7188154d7 Need -DAG in the first expect statement too | 4 年前 | |
[lld-macho][nfc] Clean up tests * Remove unnecessary rm -rf %ts * Have lc-linker-option.ll use the right comment marker | 5 年前 | |
[lld-macho][test] Remove ld64.lld: prefix in a diagnostic The convention is not to check the prefix before error: . This gives flexibility if we need to rename ld64.lld to something else, (e.g. a while ago we used ld64.lld.darwinnew). | 4 年前 | |
[lld-macho] Fix assertion when two symbols at same addr have unwind info If there are multiple symbols at the same address, our unwind info implementation assumes that we always register unwind entries to a single canonical symbol. This assumption was violated by the registerEhFrame code. Fixes #56570. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D130208 | 3 年前 | |
[MachO] Use error instead of fatal for missing -arch fatal should only be used for malformed inputs according to ErrorHandler.h; error is more appropriate for missing arguments, accompanied by a check to bail out early in case of the error. Some tests need to be adjusted accordingly. Makes lld/test/MachO/arch.s pass with LLD_IN_TEST=2. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D112879 | 4 年前 | |
[llvm-objdump] Print memory operand addresses as regular comments The patch reuses the common code to print memory operand addresses as instruction comments. This helps to align the comments and enables using target-specific comment markers when evaluateMemoryOperandAddress() is implemented for them. Differential Revision: https://reviews.llvm.org/D104861 | 4 年前 | |
[ADT] [lld-macho] Check for end iterator deref in filter_iterator_base If ld64.lld was supplied an object file that had a __debug_abbrev or __debug_str section, but didn't have any compile unit DIEs in __debug_info, it would dereference an iterator pointing to the empty array of DIEs. This underlying issue started causing segmentation faults when parsing for __debug_info was addded in D128184. That commit was reverted, and this one fixes the invalid dereference to allow relanding it. This commit adds an assertion to filter_iterator_base's dereference operators to catch bugs like this one. Ran check-llvm, check-clang and check-lld. Differential Revision: https://reviews.llvm.org/D128294 | 3 年前 | |
[lld/mac] Always reference dyld_stub_binder when linked with libSystem lld currently only references dyld_stub_binder when it's needed. ld64 always references it when libSystem is linked. Match ld64. The (somewhat lame) motivation is that nm on a binary without any export writes a "no symbols" warning to stderr, and this change makes it so that every binary in practice has at least a reference to dyld_stub_binder, which suppresses that. Every "real" output file will reference dyld_stub_binder, so most of the time this shouldn't make much of a difference. And if you really don't want to have this reference for whatever reason, you can stop passing -lSystem, like you have to for ld64 anyways. (After linking any dylib, we dump the exported list of symbols to a txt file with nm and only relink downstream deps if that txt file changes. A nicer fix is to make lld optionally write .tbd files with the public interface of a linked dylib and use that instead, but for now the txt files are what we do.) Differential Revision: https://reviews.llvm.org/D105782 | 4 年前 | |
[yaml2obj][MachO] Rename PayloadString to Content The new name is conciser and matches yaml2obj ELF & DWARF. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D106759 | 4 年前 | |
[mac/lld] simplify code using PackedVersion instead of VersionTuple PackedVersion already does the correct range checks. No behavior change. Differential Revision: https://reviews.llvm.org/D93338 | 5 年前 | |
[lld-macho] Always include custom syslibroot when running tests This greatly reduces the amount of boilerplate in our tests. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D87960 | 5 年前 | |
[lld/mac] Make tbd files in one test valid No behavior change, but ld64 can't load .tbd files without the trailing ..., so include them to make it easier to run tests with l64 too. | 4 年前 | |
[lld/mac] fill in current and compatibility version for LC_LOAD_(WEAK_)DYLIB Not sure if anything actually depends on this, but it makes otool -L output look nicer. Differential Revision: https://reviews.llvm.org/D93332 | 5 年前 | |
[MachO] Fix dead-stripping __eh_frame This section is marked S_ATTR_LIVE_SUPPORT in input files, which meant that on arm64, we were unnecessarily preserving FDEs if we e.g. had multiple weak definitions for a function. Worse, we would actually produce an invalid __eh_frame section in that case, because the CIE associated with the unnecessary FDE would still get dead-stripped and we'd end up with a dangling FDE. We set up associations from functions to their FDEs, so dead-stripping will just work naturally, and we can clear S_ATTR_LIVE_SUPPORT from our input __eh_frame sections to fix dead-stripping. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D132489 (cherry picked from commit a745e47900dde15c180d5caea7a1d292ca809eb1) | 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] 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] Require aarch64 for eh-frame.s test Should fix the test failure introduced by D124561. | 3 年前 | |
[lld/mac] add aarch64 to requirements of encryption-info.s test | 5 年前 | |
[lld-macho] Treat undefined symbols uniformly In particular, we should apply the -undefined behavior to all such symbols, include those that are specified via the command line (i.e. -e, -u, and -exported_symbol). ld64 supports this too. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D102143 | 5 年前 | |
[lld] Add test suite mode for running LLD main twice LLD_IN_TEST determines how many times each port's main function is run in each LLD process, and setting LLD_IN_TEST=2 (or higher) is useful for checking if we're cleaning up and resetting global state correctly. Add a test suite parameter to enable this easily. There's work in progress to remove global state (e.g. D108850), but this seems useful in the interim. Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D112898 | 4 年前 | |
[lld-macho] Add support for exporting no symbols As an optimization for ld64 sometimes it can be useful to not export any symbols for top level binaries that don't need any exports, to do this you can pass -exported_symbols_list /dev/null, or new with Xcode 14 (ld64 816) there is a -no_exported_symbols flag for the same behavior. This reproduces this behavior where previously an empty exported symbols list file would have been ignored. Differential Revision: https://reviews.llvm.org/D127562 | 3 年前 | |
[lld-macho] Have tests default to targeting macos 10.15 D101114 enforced proper version checks, which exposed a variety of version mismatch issues in our tests. We previously changed the test inputs to target 10.0, which was the simpler thing to do, but we should really just have our lit.local.cfg default to targeting 10.15, which is what is done here. We're not likely to ever have proper support for the older versions anyway, as that would require more work for unclear benefit; for instance, llvm-mc seems to generate a different compact unwind format for older macOS versions, which would cause our compact-unwind.s test to fail. Targeting 10.15 by default causes the following behavioral changes: * __mh_execute_header is now a section symbol instead of an absolute symbol * LC_BUILD_VERSION gets emitted instead of LC_VERSION_MIN_MACOSX. The former is 32 bytes in size whereas the latter is 16 bytes, so a bunch of hardcoded address offsets in our tests had to be updated. * >= 10.6 executables are PIE by default Note that this diff was stacked atop of a local revert of most of the test changes in rG8c17a875150f8e736e8f9061ddf084397f45f4c5, to make review easier. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D101119 | 5 年前 | |
[lld-macho] Always include custom syslibroot when running tests This greatly reduces the amount of boilerplate in our tests. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D87960 | 5 年前 | |
[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 年前 | |
[lld-macho][nfc] Clean up tests * Migrate most of our tests to use split-file instead of echo * Remove individual rm -f %t/libfoo.a commands in favor of a top-level rm -rf %t * Remove unused Inputs/libfunction.s Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D93604 | 5 年前 | |
[lld/mac] Implement -final_output This is one of two flags clang passes to the linker when giving calling clang with multiple -arch flags. I think it'd make sense to also use finalOutput instead of outputFile in CodeSignatureSection() and when replacing @executable_path, but ld64 doesn't do that, so I'll at least put those in separate commits. Differential Revision: https://reviews.llvm.org/D105449 | 4 年前 | |
[lld-macho] -flat_namespace for dylibs should make all externs interposable All references to interposable symbols can be redirected at runtime to point to a different symbol definition (with the same name). For example, if both dylib A and B define symbol _foo, and we load A before B at runtime, then all references to _foo within dylib B will point to the definition in dylib A. ld64 makes all extern symbols interposable when linking with -flat_namespace. TODO 1: Support -interposable and -interposable_list, which should just be a matter of parsing those CLI flags and setting the Defined::interposable bit. TODO 2: Set Reloc::FinalDefinitionInLinkageUnit correctly with this info (we are currently not setting it at all, so we're erring on the conservative side, but we should help the LTO backend generate more optimal code.) Reviewed By: modimo, MaskRay Differential Revision: https://reviews.llvm.org/D119294 | 4 年前 | |
[lld-macho] -flat_namespace for dylibs should make all externs interposable All references to interposable symbols can be redirected at runtime to point to a different symbol definition (with the same name). For example, if both dylib A and B define symbol _foo, and we load A before B at runtime, then all references to _foo within dylib B will point to the definition in dylib A. ld64 makes all extern symbols interposable when linking with -flat_namespace. TODO 1: Support -interposable and -interposable_list, which should just be a matter of parsing those CLI flags and setting the Defined::interposable bit. TODO 2: Set Reloc::FinalDefinitionInLinkageUnit correctly with this info (we are currently not setting it at all, so we're erring on the conservative side, but we should help the LTO backend generate more optimal code.) Reviewed By: modimo, MaskRay Differential Revision: https://reviews.llvm.org/D119294 | 4 年前 | |
[lld-macho] Simplify archive loading logic This is a follow-on to {D129556}. I've refactored the code such that addFile() no longer needs to take an extra parameter. Additionally, the "do we force-load or not" policy logic is now fully contained within addFile, instead of being split between addFile and parseLCLinkerOptions. This also allows us to move the ForceLoad (now LoadType) enum out of the header file. Additionally, we can now correctly report loads induced by LC_LINKER_OPTION in our -why_load output. I've also added another test to check that CLI library non-force-loads take precedence over LC_LINKER_OPTION + -force_load_swift_libs. (The existing logic is correct, just untested.) Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D130137 | 3 年前 | |
[lld-macho][nfc] Change force-load.s test to actually test I'd forgotten to change a copypasted line... | 3 年前 | |
[lld/mac] Make framework symlinks in tests more realistic In a framework Foo.framework, Foo.framework/Foo is usually a relative symbolic link to Foo.framework/Versions/Current/Foo, and Foo.framework/Versions/Current is usually a relative symbolic link to A. Our tests used absolute symbolic links. Now they use relative symbolic links. No behavior change, just makes the tests more representative of the real world. (implicit-dylib.s omits the "Current" folder too, but I'm not changing that here.) Differential Revision: https://reviews.llvm.org/D103998 | 4 年前 | |
[test][lld-macho] Improve LC_FUNCTION_STARTS test coverage Previously functions that aren't included in the symtab were also excluded from the function starts. Symbols missing from function starts degrades the debugger experience in the case you don't have debug info for them. Differential Revision: https://reviews.llvm.org/D114275 | 4 年前 | |
[lld-macho] Initial scaffolding for ARM32 support This just parses the -arch armv7 and emits the right header flags. The rest will be slowly fleshed out in upcoming diffs. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D101557 | 5 年前 | |
[lld][MachO] Add support for LC_DATA_IN_CODE Add first bits for emitting LC_DATA_IN_CODE. Test plan: make check-lld-macho Differential revision: https://reviews.llvm.org/D103006 | 4 年前 | |
[lld/mac] Don't assert when ICFing arm64 code WordLiteralSection dedupes literals by content. WordLiteralInputSection::getOffset() used to read a literal at the passed-in offset and look up this value in the deduping map to find the offset of the deduped value. But it's possible that (e.g.) a 16-byte literal's value is accessed 4 bytes in. To get the offset at that address, we have to get the deduped value at offset 0 and then apply the offset 4 to the result. (See also WordLiteralSection::finalizeContents() which fills in those maps.) Only a problem on arm64 because in x86_64 the offset is part of the instruction instead of a separate ARM64_RELOC_ADDEND relocation. (See bug for more details.) Fixes PR51999. Differential Revision: https://reviews.llvm.org/D112584 | 4 年前 | |
[lld-macho] Fix ICF crash when comparing symbol relocs Previously, when encountering a symbol reloc located in a literal section, we would look up the contents of the literal at the symbol value + addend offset within the literal section. However, it seems that this offset is not guaranteed to be valid. Instead, we should use just the symbol value to retrieve the literal's contents, and compare the addend values separately. ld64 seems to do this. Reviewed By: #lld-macho, thevinster Differential Revision: https://reviews.llvm.org/D124223 | 4 年前 | |
[lld] Implement safe icf for MachO This change implements --icf=safe for MachO based on addrsig section that is implemented in D123751. Reviewed By: int3, #lld-macho Differential Revision: https://reviews.llvm.org/D123752 | 4 年前 | |
[lld-macho] Make --icf=safe work with LTO Just matter of enabling the config option. (Also changed the platform of the input test file to macOS, since that's the default that we specify in the %lld substitution. The conflict was causing errors when linking with LTO.) Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D127600 | 3 年前 | |
[lld-macho][nfc] Clean up trailing spaces and tabs | 4 年前 | |
[lld-macho] Deduplicate CFStrings during ICF __cfstring has embedded addends that foil ICF's hashing / equality checks. (We can ignore embedded addends when doing ICF because the same information gets recorded in our Reloc structs.) Therefore, in order to properly dedup CFStrings, we create a mutable copy of the CFString and zero out the embedded addends before performing any hashing / equality checks. (We did in fact have a partial implementation of CFString deduplication already. However, it only worked when the cstrings they point to are at identical offsets in their object files.) I anticipate this approach can be extended to other similar statically-allocated struct sections in the future. In addition, we previously treated all references with differing addends as unequal. This is not true when the references are to literals: different addends may point to the same literal in the output binary. In particular, __cfstring has such references to __cstring. I've adjusted ICF's equalsConstant logic accordingly, and I've added a few more tests to make sure the addend-comparison code path is adequately covered. Fixes https://github.com/llvm/llvm-project/issues/51281. Reviewed By: #lld-macho, Roger Differential Revision: https://reviews.llvm.org/D120137 | 4 年前 | |
[lld-macho] Support folding of functions with identical LSDAs To do this, we need to slice away the LSDA pointer, just like we are slicing away the functionAddress pointer. No observable difference in perf on chromium_framework: base diff difference (95% CI) sys_time 1.769 ± 0.068 1.761 ± 0.065 [ -2.7% .. +1.8%] user_time 9.517 ± 0.110 9.528 ± 0.116 [ -0.6% .. +0.8%] wall_time 8.291 ± 0.174 8.307 ± 0.183 [ -1.1% .. +1.5%] samples 21 25 Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D129830 | 3 年前 | |
[lld/mac] Make framework symlinks in tests more realistic In a framework Foo.framework, Foo.framework/Foo is usually a relative symbolic link to Foo.framework/Versions/Current/Foo, and Foo.framework/Versions/Current is usually a relative symbolic link to A. Our tests used absolute symbolic links. Now they use relative symbolic links. No behavior change, just makes the tests more representative of the real world. (implicit-dylib.s omits the "Current" folder too, but I'm not changing that here.) Differential Revision: https://reviews.llvm.org/D103998 | 4 年前 | |
[lld/mac] Mark private externs with GOT relocs as LOCAL in indirect symbtab prepareSymbolRelocation() in Writer.cpp adds both symbols that need binding and symbols relocated with a pointer relocation to the got. Pointer relocations are emitted for non-movq GOTPCREL(%rip) loads. (movqs become GOT_LOADs so that the linker knows they can be relaxed to leaqs, while others, such as addq, become just GOT -- a pointer relocation -- since they can't be relaxed in that way). For example, this C file produces a private_extern GOT relocation when compiled with -O2 with clang: extern const char kString[]; const char* g(int a) { return kString + a; } Linkers need to put pointer-relocated symbols into the GOT, but ld64 marks them as LOCAL in the indirect symbol table. This matters, since strip -x looks at the indirect symbol table when deciding what to strip. The indirect symtab emitting code was assuming that only symbols that need binding are in the GOT, but pointer relocations where there too. Hence, the code needs to explicitly check if a symbol is a private extern. Fixes https://crbug.com/1242638, which has some more information in comments 14 and 15. With this patch, the output of nm -U on Chromium Framework after stripping now contains just two symbols when using lld, just like with ld64. Differential Revision: https://reviews.llvm.org/D111852 | 4 年前 | |
[lld-macho][nfc] Rename %no_fatal_warnings_lld in tests ... to use hyphens instead of underscores, making it consistent with our other substitutions like %no-arg-lld and %lld-watchos. Reviewed By: keith Differential Revision: https://reviews.llvm.org/D119513 | 4 年前 | |
[lld/mac] Warn that writing zippered outputs isn't implemented A "zippered" dylib contains several LC_BUILD_VERSION load commands, usually one each for "normal" macOS and one for macCatalyst. These are usually created by passing something like -shared -target arm64-apple-macos -darwin-target-variant arm64-apple-ios13.1-macabi to clang, which turns it into -platform_version macos 12.0.0 12.3 -platform_version "mac catalyst" 14.0.0 15.4 for the linker. ld64.lld can read these files fine, but it can't write them. Before this change, it would just silently use the last -platform_version flag and ignore the rest. This change adds a warning that writing zippered dylibs isn't implemented yet instead. Sadly, parts of ld64.lld's test suite relied on the previous "silently use last flag" semantics for its test suite: %lld always expanded to ld64.lld -platform_version macos 10.15 11.0 and tests that wanted a different value passed a 2nd -platform_version flag later on. But this now produces a warning if the platform passed to -platform_version is not macos. There weren't very many cases of this, so move these to use %no-arg-lld and manually pass -arch. Differential Revision: https://reviews.llvm.org/D124106 | 4 年前 | |
[lld-macho] Accept dylibs with LC_DYLD_EXPORTS_TRIE This load command specifies the offset and size of the exports trie. This information used to be a field in LC_DYLD_INFO, but in newer libraries, it has a dedicated load command: LC_DYLD_EXPORTS_TRIE. The format of the trie is the same for both load commands, so the code for parsing it can be shared. LLD does not generate this yet; it is mainly useful when chained fixups are in use, as the other members of LC_DYLD_INFO are unused then, so the smaller LC_DYLD_EXPORTS_TRIE can be output instead. LLDB gained support for this in D107673. Fixes #54550 Differential Revision: https://reviews.llvm.org/D129430 | 3 年前 | |
[lld-macho] Fix loading same libraries from both LC_LINKER_OPTION and command line This fixes https://github.com/llvm/llvm-project/issues/56059 and https://github.com/llvm/llvm-project/issues/56440. This is inspired by tapthaker's patch (https://reviews.llvm.org/D127941), and has reused his test cases. This patch adds an bool "isCommandLineLoad" to indicate where archives are from. If lld tries to load the same library loaded previously by LC_LINKER_OPTION from CLI, it will use this isCommandLineLoad to determine if it should be affected by -all_load & -ObjC flags. This also prevents -force_load from affecting archives loaded previously from CLI without such flag, whereas tapthaker's patch will fail such test case (introduced by https://reviews.llvm.org/D128025). Reviewed By: int3, #lld-macho Differential Revision: https://reviews.llvm.org/D129556 | 3 年前 | |
[lld/mac] Implement support for searching dylibs with @executable_path/ in install name Differential Revision: https://reviews.llvm.org/D103775 | 4 年前 | |
[lld/mac] When handling @loader_path, use realpath() of symlinks This is important for Frameworks, which are usually symlinks. ld64 gets this right for @rpath that's replaced with @loader_path, but not for bare @loader_path -- ld64's code calls realpath() in that case too, but ignores the result. ld64 somehow manages to find libbar1.dylib in the test without the explicit -rpath in Foo1. I don't understand why or how. But this change is a step forward and fixes an immediate problem I'm having, so let's start with this :) Differential Revision: https://reviews.llvm.org/D103990 | 4 年前 | |
[lld/mac] Implement support for searching dylibs with @loader_path/ in install name Differential Revision: https://reviews.llvm.org/D103779 | 4 年前 | |
[lld/mac] Implement support for searching dylibs with @rpath/ in install name Also adjust a few comments, and move the DylibFile comment talking about umbrella next to the parameter again. Differential Revision: https://reviews.llvm.org/D103783 | 4 年前 | |
[lld/mac] Search .tbd before binary for framework files too This matters for example for the iPhoneSimulator14.0.sdk, which has a System/Library/Frameworks/UIKit.framework/UIKit that has LC_BUILD_VERSION with minos of 14.0, so linking against that file will produce warnings like: .../iPhoneSimulator14.0.sdk/System/Library/Frameworks/UIKit.framework/UIKit has version 14.0.0, which is newer than target minimum of 12.0.0 when targeting x86_64-apple-ios12.0-simulator. That doens't happen when linking against UIKit.tbd instead, obviously. Linking with RC_TRACE_DYLIB_SEARCHING=1 shows that ld64 also searches the tbd file first, and we already get that right for non-framework dylibs. Fixes crbug.com/1249456. Differential Revision: https://reviews.llvm.org/D109768 | 4 年前 | |
fix typos to cycle bots | 4 年前 | |
[lld-macho][nfc] Set test min version to 11.0 The arm64-apple-macos triple is only valid for versions >= 11.0. (If one passes arm64-apple-macos10.15 to llvm-mc, the output's min version is still 11.0). In order to write tests easily for both target archs, let's up the default min version in our tests. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D124562 | 4 年前 | |
[lld-macho] Allow deduplicate-literals to be overridden It's still uncertain but whether we want to have deduplicate-literals be the default flag for LLD out of the box or not. If deduplicate-literals is the default behavior, then we will need a way override it and not deduplicate. Luckily, we have no_deduplicate to fill this gap. For now, I've set the default to be false which aligns with the existing behavior. That can only always be changed after discussions on D117250. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D117387 | 4 年前 | |
[lld/mac] Change load command order to be more like ld64 No meaningful behavior change. Makes diffing otool -l output a bit easier. Differential Revision: https://reviews.llvm.org/D106219 | 4 年前 | |
[mac/lld] Run tests with -fatal_warnings by default This helps us catch cases where we add support for a flag but forget to remove HelpHidden from Options.td. More explicit alternative to D92455 Differential Revision: https://reviews.llvm.org/D92575 | 5 年前 | |
Reland "[lld-macho] Implement -load_hidden" This flag was introduced in ld64-609. It instructs the linker to link to a static library while treating its symbols as if they had hidden visibility. This is useful when building a dylib that links to static libraries but we don't want the symbols from those to be exported. Closes #51505 This reland adds bitcode file handling, so we won't get any compile errors due to BitcodeFile::forceHidden being unused. Differential Revision: https://reviews.llvm.org/D130473 | 3 年前 | |
[lld-macho] Implement -hidden-l Similarly to -load_hidden, this flag instructs the linker to not export symbols from the specified archive. While that flag takes a path, -hidden-l looks for the specified library name in the search path. The test changes are needed because -hidden-lfoo resolves to libfoo.a, not foo.a. Differential Revision: https://reviews.llvm.org/D130529 | 3 年前 | |
[lld][MachO] Add support for LC_DATA_IN_CODE Add first bits for emitting LC_DATA_IN_CODE. Test plan: make check-lld-macho Differential revision: https://reviews.llvm.org/D103006 | 4 年前 | |
[lld-macho] Handle non-extern symbols marked as private extern Previously, we asserted that such a case was invalid, but in fact ld -r can emit such symbols if the input contained a (true) private extern, or if it contained a symbol started with "L". Non-extern symbols marked as private extern are essentially equivalent to regular TU-scoped symbols, so no new functionality is needed. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D104502 | 4 年前 | |
[lld-macho] Support -non_global_symbols_strip_list, -non_global_symbols_no_strip_list, -x PR/55600 Differential Revision: https://reviews.llvm.org/D126046 | 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 年前 | |
[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 年前 | |
fix comment typo to cycle bots | 3 年前 | |
[lld-macho] Handle LOH_ARM64_ADRP_LDR_GOT optimization hints This hint instructs the linker to perform the AdrpLdr or AdrpAdd transformation depending on whether the GOT load has been relaxed to load a local symbol's address. Differential Revision: https://reviews.llvm.org/D129059 | 3 年前 | |
[lld-macho] Handle LOH_ARM64_ADRP_LDR linker optimization hints This linker optimization hint transforms a pair of adrp+ldr (immediate) instructions into an ldr (literal) load from a PC-relative address if it is 4-byte aligned and within +/- 1 MiB, as ldr can encode a signed 19-bit offset that gets multiplied by 4. In the wild, only a small number of these hints are applicable because not many loads end up close enough to the data segment. However, the added helper functions will be useful in implementing the rest of the LOH types. Differential Revision: https://reviews.llvm.org/D128942 | 3 年前 | |
[lld-macho] Fix LOH parsing segfault advanceSubsection() didn't account for the possibility that a section could have no subsections. Reviewed By: #lld-macho, thakis, BertalanD Differential Revision: https://reviews.llvm.org/D130288 | 3 年前 | |
[lld-macho] Include archive name in bitcode files Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D115281 | 4 年前 | |
[lld/mac] Add missing REQUIRES line to new test | 4 年前 | |
[Support] Use final filename for Caching buffer identifier Mach-O LLD uses the buffer identifier of the memory buffer backing an object file to generate stabs which are used by dsymutil to find the object file for dSYM generation. When using thinLTO, these buffers are provided by the cache which initially saves them to disk as temporary files beginning with "Thin-" but renames them to persistent files beginning with "llvmcache-" before the buffer is provided to the cache user. However, the buffer is created before the file is renamed and is given the temp file's name as an identifier. This causes the generated stabs to point to nonexistent files. This change names the buffer with the eventual persistent filename. I think this is safe because failing to rename the temp file is a fatal error. Differential Revision: https://reviews.llvm.org/D115055 | 4 年前 | |
[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/mac] Give several LTO tests an "lto-" prefix Differential Revision: https://reviews.llvm.org/D105476 | 4 年前 | |
[lld-macho] Support common symbols in bitcode (but differently from ld64) ld64 seems to handle common symbols in bitcode rather bizarrely. They follow entirely different precedence rules from their non-bitcode counterparts. I initially tried to emulate ld64 in D106597, but I'm not sure the extra complexity is worth it, especially given that common symbols are not, well, very common. This diff accords common bitcode symbols the same precedence as regular common symbols, just as we treat all other pairs of bitcode and non-bitcode symbol types. The tests document ld64's behavior in detail, just in case we want to revisit this. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D107027 | 4 年前 | |
[lld-macho] Support common symbols in bitcode (but differently from ld64) ld64 seems to handle common symbols in bitcode rather bizarrely. They follow entirely different precedence rules from their non-bitcode counterparts. I initially tried to emulate ld64 in D106597, but I'm not sure the extra complexity is worth it, especially given that common symbols are not, well, very common. This diff accords common bitcode symbols the same precedence as regular common symbols, just as we treat all other pairs of bitcode and non-bitcode symbol types. The tests document ld64's behavior in detail, just in case we want to revisit this. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D107027 | 4 年前 | |
[lld/mac] Give several LTO tests an "lto-" prefix Differential Revision: https://reviews.llvm.org/D105476 | 4 年前 | |
[lld-macho] Set FinalDefinitionInLinkageUnit on most LTO externs Since Mach-O has a two-level namespace (unlike ELF), we can usually set this property to true. (I believe this setting is only available in the new LTO backend, so I can't really use ld64 / libLTO's behavior as a reference here... I'm just doing what I think is correct.) See {D119294} for the work done to calculate the interposable used in this diff. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D119506 | 4 年前 | |
[lld-macho] Extend lto-internalize-unnamed-addr.ll * Test the case where a symbol is sometimes linkonce_odr and sometimes weak_odr * Test the visibility of the symbols at the IR level, after the internalize stage of LTO is done. (Previously we only checked the visibility of symbols in the final output binary.) Reviewed By: modimo Differential Revision: https://reviews.llvm.org/D121428 | 4 年前 | |
[lld-macho] Set FinalDefinitionInLinkageUnit on most LTO externs Since Mach-O has a two-level namespace (unlike ELF), we can usually set this property to true. (I believe this setting is only available in the new LTO backend, so I can't really use ld64 / libLTO's behavior as a reference here... I'm just doing what I think is correct.) See {D119294} for the work done to calculate the interposable used in this diff. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D119506 | 4 年前 | |
[lld-macho][nfc] Rename %no_fatal_warnings_lld in tests ... to use hyphens instead of underscores, making it consistent with our other substitutions like %no-arg-lld and %lld-watchos. Reviewed By: keith Differential Revision: https://reviews.llvm.org/D119513 | 4 年前 | |
[lld/mac] Give several LTO tests an "lto-" prefix Differential Revision: https://reviews.llvm.org/D105476 | 4 年前 | |
lld test fix: don't check the precise hex emitted as a comment. It can vary depending on the platform, so as with the NO-FMA test just check for "0x". | 3 年前 | |
[lld] Add module name to LTO inline asm diagnostic Close #52781: for LTO, the inline asm diagnostic uses <inline asm> as the file name (lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp) and it is unclear which module has the issue. With this patch, we will see the module name (say asm.o) before <inline asm> with ThinLTO. % clang -flto=thin -c asm.c && myld.lld asm.o -e f ld.lld: error: asm.o <inline asm>:1:2: invalid instruction mnemonic 'invalid' invalid ^~~~~~~ For regular LTO, unfortunately the original module name is lost and we only get ld-temp.o. Reviewed By: #lld-macho, ychen, Jez Ng Differential Revision: https://reviews.llvm.org/D118434 | 4 年前 | |
[lld/mac] Give several LTO tests an "lto-" prefix Differential Revision: https://reviews.llvm.org/D105476 | 4 年前 | |
[lld-macho] Fix segfault when handling LTO + object file weak defs which occurs when there are EH frames present in the object file's weak def. Reviewed By: abrachet Differential Revision: https://reviews.llvm.org/D130409 | 3 年前 | |
[lld] Remove support for legacy pass manager This removes options for performing LTO with the legacy pass manager in LLD. Options that explicitly enable the new pass manager are retained as no-ops. Differential Revision: https://reviews.llvm.org/D123219 | 4 年前 | |
[lld-macho] Handle filename being passed in -lto_object_path Clang passes a filename rather than a directory in -lto_object_path when using FullLTO. Previously, it was always treated it as a directory, so lld would crash when it attempted to create temporary files inside it. Fixes #54805 Differential Revision: https://reviews.llvm.org/D129705 | 3 年前 | |
[lld/mac] Add test for --lto-O This belongs to fe08e9c4871, I (thakis) forgot to git add it back then. Differential Revision: https://reviews.llvm.org/D105223 | 4 年前 | |
[lld-macho] Have tests default to targeting macos 10.15 D101114 enforced proper version checks, which exposed a variety of version mismatch issues in our tests. We previously changed the test inputs to target 10.0, which was the simpler thing to do, but we should really just have our lit.local.cfg default to targeting 10.15, which is what is done here. We're not likely to ever have proper support for the older versions anyway, as that would require more work for unclear benefit; for instance, llvm-mc seems to generate a different compact unwind format for older macOS versions, which would cause our compact-unwind.s test to fail. Targeting 10.15 by default causes the following behavioral changes: * __mh_execute_header is now a section symbol instead of an absolute symbol * LC_BUILD_VERSION gets emitted instead of LC_VERSION_MIN_MACOSX. The former is 32 bytes in size whereas the latter is 16 bytes, so a bunch of hardcoded address offsets in our tests had to be updated. * >= 10.6 executables are PIE by default Note that this diff was stacked atop of a local revert of most of the test changes in rG8c17a875150f8e736e8f9061ddf084397f45f4c5, to make review easier. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D101119 | 5 年前 | |
[lld-macho][nfc] Add test for resolution of bitcode symbols We lacked a test for bitcode symbol precedence. We assumed that they followed the same rules as their regular symbol counterparts, but never had a test to verify that we were matching ld64's behavior. It turns out that we were largely correct, though we deviate from ld64 when there are bitcode and non-bitcode symbols of the same name. The test added in this diff both verifies our behavior and documents the differences. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D106596 | 4 年前 | |
[lld/mac] Don't lose "weak ref" bit when doing LTO Fixes #52778. Probably fixes Chromium crashing on startup on macOS 10.15 (and older) systems when building with LTO, but I haven't verified that yet. Differential Revision: https://reviews.llvm.org/D115949 | 4 年前 | |
[lld-macho][nfc] Use %X in mapfile test LLD (and ld64) emits uppercase hex addresses in the mapfile. The map-file.s test passes right now because the addresses we emit happen not to include any alphabets, but that can easily change. I noticed this while dealing with https://github.com/llvm/llvm-project/issues/54184. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D120941 | 4 年前 | |
[lld-macho][nfc] Rename %no_fatal_warnings_lld in tests ... to use hyphens instead of underscores, making it consistent with our other substitutions like %no-arg-lld and %lld-watchos. Reviewed By: keith Differential Revision: https://reviews.llvm.org/D119513 | 4 年前 | |
[lld-macho][nfc] Remove unnecessary -pie flags in tests D101513 means that we no longer need to specify -pie in most of our test RUN commands. Let's clean up the unused flags so as not to confuse future test writers. Reviewed By: #lld-macho, oontvoo, MaskRay Differential Revision: https://reviews.llvm.org/D113114 | 4 年前 | |
[lld-macho][nfc] Remove unnecessary -pie flags in tests D101513 means that we no longer need to specify -pie in most of our test RUN commands. Let's clean up the unused flags so as not to confuse future test writers. Reviewed By: #lld-macho, oontvoo, MaskRay Differential Revision: https://reviews.llvm.org/D113114 | 4 年前 | |
[lld-macho] Always include custom syslibroot when running tests This greatly reduces the amount of boilerplate in our tests. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D87960 | 5 年前 | |
[lld-macho] If export_size is zero, export_off must be zero Otherwise tools like codesign_allocate will choke. We were already handling this correctly for the other DYLD_INFO sections. Doing this correctly is a bit subtle: we don't know if export_size will be zero until we have run ExportSection::finalizeContents(). However, we must still add the ExportSection to the __LINKEDIT segment in order that it gets sorted during sortSectionsAndSegments(). Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D112589 | 4 年前 | |
fix typos to cycle bots | 4 年前 | |
[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 年前 | |
[lld-macho] Deduplicate the __objc_classrefs section contents ld64 breaks down __objc_classrefs on a per-word level and deduplicates them. This greatly reduces the number of bind entries emitted (and therefore the amount of work dyld has to do at runtime). For chromium_framework, this change to LLD cuts the number of (non-lazy) binds from 912 to 190, getting us to parity with ld64 in this aspect. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D121053 | 4 年前 | |
[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 年前 | |
[lld/mac] Warn that writing zippered outputs isn't implemented A "zippered" dylib contains several LC_BUILD_VERSION load commands, usually one each for "normal" macOS and one for macCatalyst. These are usually created by passing something like -shared -target arm64-apple-macos -darwin-target-variant arm64-apple-ios13.1-macabi to clang, which turns it into -platform_version macos 12.0.0 12.3 -platform_version "mac catalyst" 14.0.0 15.4 for the linker. ld64.lld can read these files fine, but it can't write them. Before this change, it would just silently use the last -platform_version flag and ignore the rest. This change adds a warning that writing zippered dylibs isn't implemented yet instead. Sadly, parts of ld64.lld's test suite relied on the previous "silently use last flag" semantics for its test suite: %lld always expanded to ld64.lld -platform_version macos 10.15 11.0 and tests that wanted a different value passed a 2nd -platform_version flag later on. But this now produces a warning if the platform passed to -platform_version is not macos. There weren't very many cases of this, so move these to use %no-arg-lld and manually pass -arch. Differential Revision: https://reviews.llvm.org/D124106 | 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/mac] Don't crash on absolute symbols in order files Absolute symbols have a nullptr isec. buildInputSectionPriorities() would defer isec, causing crashes. Ordering absolute symbols doesn't make sense, so just ignore them. This seems to match ld64. Differential Revision: https://reviews.llvm.org/D106628 | 4 年前 | |
[lld-macho][nfc] Rename %no_fatal_warnings_lld in tests ... to use hyphens instead of underscores, making it consistent with our other substitutions like %no-arg-lld and %lld-watchos. Reviewed By: keith Differential Revision: https://reviews.llvm.org/D119513 | 4 年前 | |
[lld/mac] Support writing zippered dylibs and bundles With -platform_version flags for two distinct platforms, this writes a LC_BUILD_VERSION header for each. The motivation is that this is needed for self-hosting with lld as linker after D124059. To create a zippered output at the clang driver level, pass -target arm64-apple-macos -darwin-target-variant arm64-apple-ios-macabi to create a zippered dylib. (In Xcode's clang, -darwin-target-variant is spelled just -target-variant.) (If you pass -target arm64-apple-ios-macabi -target-variant arm64-apple-macos instead, ld64 crashes!) This results in two -platform_version flags being passed to the linker. ld64 also verifies that the iOS SDK version is at least 13.1. We don't do that yet. But ld64 also does that for other platforms and we don't. So we need to do that at some point, but not in this patch. Only dylib and bundle outputs can be zippered. I verified that a Catalyst app linked against a dylib created with clang -shared foo.cc -o libfoo.dylib \ -target arm64-apple-macos \ -target-variant arm64-apple-ios-macabi \ -Wl,-install_name,@rpath/libfoo.dylib \ -fuse-ld=$PWD/out/gn/bin/ld64.lld runs successfully. (The app calls a function f() in libfoo.dylib that returns a const char* "foo", and NSLog(@"%s")s it.) ld64 is a bit more permissive when writing zippered outputs, see references to "unzippered twins". That's not implemented yet. (If anybody wants to implement that, D124275 is a good start.) Differential Revision: https://reviews.llvm.org/D124887 | 4 年前 | |
[lld-macho][NFC] Purge stale test-output trees prior to split-file Enforce standard practice Differential Revision: https://reviews.llvm.org/D102112 | 5 年前 | |
[lld-macho] Optimize rebase opcode generation This commit reduces the size of the emitted rebase sections by generating the REBASE_OPCODE_DO_REBASE_ADD_ADDR_ULEB and REBASE_OPCODE_DO_REBASE_ULEB_TIMES_SKIPPING_ULEB opcodes. With this change, chromium_framework's rebase section is a 40% smaller 197 kilobytes, down from the previous 320 kB. That is 6 kB smaller than what ld64 produces for the same input. Performance figures from my M1 Mac mini: x before + after N Min Max Median Avg Stddev x 10 4.2269349 4.3300061 4.2689675 4.2690016 0.031151669 + 10 4.219331 4.2914009 4.2398136 4.2448277 0.023817308 No difference proven at 95.0% confidence Differential Revision: https://reviews.llvm.org/D130180 | 3 年前 | |
[lld-macho] Implement -no_implicit_dylibs Dylibs that are "public" -- i.e. top-level system libraries -- are considered implicitly linked when another library re-exports them. That is, we should load them & bind directly to their symbols instead of via their re-exporting umbrella library. This diff implements that behavior by default, as well as an opt-out flag. In theory, this is just a performance optimization, but in practice it seems that it's needed for correctness. Fixes llvm.org/PR48395. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D93000 | 5 年前 | |
fix typos to cycle bots | 4 年前 | |
[lld-macho] Support subtractor relocations that reference sections The minuend (but not the subtrahend) can reference a section. Note that we do not yet properly validate that the subtrahend isn't referencing a section; I've filed PR50034 to track that. I've also extended the reloc-subtractor.s test to reorder symbols, to make sure that the addends are being associated with the minuend (and not the subtrahend) relocation. Fixes PR49999. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D100804 | 5 年前 | |
[lld][MachO] Fix typo in rename.s | 4 年前 | |
[mac/lld] Make --reproduce work with thin archives See http://reviews.llvm.org/rL268229 and http://reviews.llvm.org/rL313832 which did the same for the ELF port. Differential Revision: https://reviews.llvm.org/D92456 | 5 年前 | |
[lld-macho][nfc] Centralize usages of ld64.lld in tests We have a mix of substituted lld ( %lld) and hard-coded lld (ld64.lld) commands. When testing with different versions of LLD, this would require going into every place where lld is hard-coded and changing that. If we centralize it, this'll only require us to modify it in only one place and will make it easy to run the same test suite. Plus, this will make it be consistent with how we write other tests. Reviewed By: #lld-macho, int3, oontvoo Differential Revision: https://reviews.llvm.org/D119394 | 4 年前 | |
Reland "[lld-macho] Implement -load_hidden" This flag was introduced in ld64-609. It instructs the linker to link to a static library while treating its symbols as if they had hidden visibility. This is useful when building a dylib that links to static libraries but we don't want the symbols from those to be exported. Closes #51505 This reland adds bitcode file handling, so we won't get any compile errors due to BitcodeFile::forceHidden being unused. Differential Revision: https://reviews.llvm.org/D130473 | 3 年前 | |
[mac/lld] Add support for response files ld64 learned about them in Xcode 12, so we should too. Differential Revision: https://reviews.llvm.org/D92149 | 5 年前 | |
[lld/mac] Implement support for searching dylibs with @rpath/ in install name Also adjust a few comments, and move the DylibFile comment talking about umbrella next to the parameter again. Differential Revision: https://reviews.llvm.org/D103783 | 4 年前 | |
[lld-macho][nfc] Centralize usages of ld64.lld in tests We have a mix of substituted lld ( %lld) and hard-coded lld (ld64.lld) commands. When testing with different versions of LLD, this would require going into every place where lld is hard-coded and changing that. If we centralize it, this'll only require us to modify it in only one place and will make it easy to run the same test suite. Plus, this will make it be consistent with how we write other tests. Reviewed By: #lld-macho, int3, oontvoo Differential Revision: https://reviews.llvm.org/D119394 | 4 年前 | |
[lld-macho] Enable search-paths tests on macOS I'm not sure what the history is here but this test passes on macOS today. It seems like we should unify these tests if they need to run cross platform. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D113085 | 4 年前 | |
[lld/mac] Implement -sectalign clang sometimes passes this flag along (see D68351), so we should implement it. Differential Revision: https://reviews.llvm.org/D102247 | 5 年前 | |
[lld-macho] Add support for -add_empty_section This is a ld64 option equivalent to -sectcreate seg sect /dev/null that's useful for creating sections like the RESTRICT section. Differential Revision: https://reviews.llvm.org/D117749 | 4 年前 | |
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the __LLVM segment is directly before __LINKEDIT by checking that fileOff + fileSize == next segment fileOff. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for __LLVM, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the __LINKEDIT segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in __LINKEDIT covers the last byte of the segment, so if we rounded up __LINKEDIT's size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more __LINKEDIT sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848 | 5 年前 | |
[lld-macho][nfc] Clean up tests * Migrate most of our tests to use split-file instead of echo * Remove individual rm -f %t/libfoo.a commands in favor of a top-level rm -rf %t * Remove unused Inputs/libfunction.s Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D93604 | 5 年前 | |
[lld-macho][nfc] Sort OutputSections based on explicit order of command-line inputs This diff paves the way for {D102964} which adds a new kind of InputSection. We previously maintained section ordering implicitly: we created InputSections as we parsed each file in command-line order, and passed on this ordering when we created OutputSections and OutputSegments by iterating over these InputSections. The implicitness of the ordering made it difficult to refactor the code to e.g. handle a new type of InputSection. As such, I've codified the ordering explicitly via inputOrder fields. This also allows us to use sort instead of stable_sort. Benchmarking chromium_framework on my 3.2 GHz 16-Core Intel Xeon W: N Min Max Median Avg Stddev x 20 4.23 4.35 4.27 4.274 0.030157481 + 20 4.24 4.38 4.27 4.2815 0.033759989 No difference proven at 95.0% confidence Reviewed By: #lld-macho, alexshap Differential Revision: https://reviews.llvm.org/D102972 | 5 年前 | |
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the __LLVM segment is directly before __LINKEDIT by checking that fileOff + fileSize == next segment fileOff. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for __LLVM, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the __LINKEDIT segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in __LINKEDIT covers the last byte of the segment, so if we rounded up __LINKEDIT's size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more __LINKEDIT sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848 | 5 年前 | |
[lld-macho] Implement -segprot Addresses llvm.org/PR49405. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D99389 | 5 年前 | |
[lld-macho] Allow deduplicate-literals to be overridden It's still uncertain but whether we want to have deduplicate-literals be the default flag for LLD out of the box or not. If deduplicate-literals is the default behavior, then we will need a way override it and not deduplicate. Luckily, we have no_deduplicate to fill this gap. For now, I've set the default to be false which aligns with the existing behavior. That can only always be changed after discussions on D117250. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D117387 | 4 年前 | |
[lld-macho][nfc] Centralize usages of ld64.lld in tests We have a mix of substituted lld ( %lld) and hard-coded lld (ld64.lld) commands. When testing with different versions of LLD, this would require going into every place where lld is hard-coded and changing that. If we centralize it, this'll only require us to modify it in only one place and will make it easy to run the same test suite. Plus, this will make it be consistent with how we write other tests. Reviewed By: #lld-macho, int3, oontvoo Differential Revision: https://reviews.llvm.org/D119394 | 4 年前 | |
[lld-macho][nfc] Clean up trailing spaces and tabs | 4 年前 | |
[lld-macho][nfc] Rename %no_fatal_warnings_lld in tests ... to use hyphens instead of underscores, making it consistent with our other substitutions like %no-arg-lld and %lld-watchos. Reviewed By: keith Differential Revision: https://reviews.llvm.org/D119513 | 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 年前 | |
[lld/mac] Don't emit stabs entries for functions folded during ICF This matches ld64, and makes dsymutil work better with lld's output. Fixes PR54783, see there for details. Reduces time needed to run dsymutil on Chromium Framework from 8m30s (which is already down from 26 min with D123218) to 6m30s and removes many lines of "could not find object file symbol for symbol" from dsymutil output (previously: several MB of those messages, now dsymutil is completely silent). Differential Revision: https://reviews.llvm.org/D123252 | 4 年前 | |
[lld-macho] Fix trailing slash in oso_prefix Previously if you passed -oso_prefix path/to/foo/ with a trailing slash at the end, using real_path would remove that slash, but that slash is necessary to make sure OSO prefix paths end up as valid relative paths instead of starting with /. Differential Revision: https://reviews.llvm.org/D113541 | 4 年前 | |
[lld][macho][NFC] Make MachO/start-end.s test less britle by checking for _main: In start-end.s there is a lit check line # SEG: _main to begin the check at the start of the function main where _main is the Darwin name mangling for C main. Because the text file that FileCheck is getting as input has the path of the compiler build in it from llvm-mc and llvm-objdump, and because of the lack of a trailing colon in this check line we end up inadvertently matching against the line of text with the compiler path in it in the case where said path contains "_main" some place. This can be very likely if the compiler branch has "main" or "_main" in it. To fix this I include the training : since that will match on the function label and not the path line. | 4 年前 | |
[lld-macho] Add --start-lib --end-lib In ld.lld, when an ObjFile/BitcodeFile is read in --start-lib state, the file is given archive semantics. --end-lib closes the previous --start-lib. A build system can use this feature as an alternative to archives. This patch ports the feature to lld-macho. --start-lib and --end-lib are positional, unlike usual ld64 options. I think the slight drawback does not matter as (a) reusing option names make build systems convenient (b) --start-lib a.o b.o --end-lib conveys more information than an alternative design: -objlib a.o -objlib b.o because --start-lib makes it clear which objects are in the same conceptual archive. This provides flexibility (c) -objlib/-filelist interaction may be weird. Close https://github.com/llvm/llvm-project/issues/52931 Reviewed By: #lld-macho, Jez Ng, oontvoo Differential Revision: https://reviews.llvm.org/D116913 | 4 年前 | |
[llvm-objdump] Print memory operand addresses as regular comments The patch reuses the common code to print memory operand addresses as instruction comments. This helps to align the comments and enables using target-specific comment markers when evaluateMemoryOperandAddress() is implemented for them. Differential Revision: https://reviews.llvm.org/D104861 | 4 年前 | |
[lld/mac] When loading reexports, look for basename in -F / -L first Matches ld64 (cf Options::findIndirectDylib()), and fixes PR51218. Differential Revision: https://reviews.llvm.org/D106842 | 4 年前 | |
[lld-macho][nfc] Clean up tests * Migrate most of our tests to use split-file instead of echo * Remove individual rm -f %t/libfoo.a commands in favor of a top-level rm -rf %t * Remove unused Inputs/libfunction.s Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D93604 | 5 年前 | |
[lld-macho][nfc] Rename some tests for consistency Now all the tests that cover symbol resolution / precedence have "resolution" in their filename. I also added a couple of extra comments. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D120938 | 4 年前 | |
[lld][macho]Fix test to sort symbol table before dumping Details: The test previously expected a specific order of those symbols, which is not guaranteed (could change simply due to hashing changes, etc). So we change it to explicitly sort the symbols before checking contents. PR/53026 Differential Revision: https://reviews.llvm.org/D116813 | 4 年前 | |
[lld-macho][nfc] Centralize usages of ld64.lld in tests We have a mix of substituted lld ( %lld) and hard-coded lld (ld64.lld) commands. When testing with different versions of LLD, this would require going into every place where lld is hard-coded and changing that. If we centralize it, this'll only require us to modify it in only one place and will make it easy to run the same test suite. Plus, this will make it be consistent with how we write other tests. Reviewed By: #lld-macho, int3, oontvoo Differential Revision: https://reviews.llvm.org/D119394 | 4 年前 | |
[lld-macho][nfc] Clean up tests * Remove unnecessary rm -rf %ts * Have lc-linker-option.ll use the right comment marker | 5 年前 | |
[lld-macho][nfc] Rename some tests "stub" is a bit too overloaded... we were using it to refer to TAPI files, but it's also the name for the PLT trampolines in Mach-O. Going ahead, let's just use "TAPI" or ".tbd" to refer to TAPI stuff. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D99807 | 5 年前 | |
[lld/mac] Warn that writing zippered outputs isn't implemented A "zippered" dylib contains several LC_BUILD_VERSION load commands, usually one each for "normal" macOS and one for macCatalyst. These are usually created by passing something like -shared -target arm64-apple-macos -darwin-target-variant arm64-apple-ios13.1-macabi to clang, which turns it into -platform_version macos 12.0.0 12.3 -platform_version "mac catalyst" 14.0.0 15.4 for the linker. ld64.lld can read these files fine, but it can't write them. Before this change, it would just silently use the last -platform_version flag and ignore the rest. This change adds a warning that writing zippered dylibs isn't implemented yet instead. Sadly, parts of ld64.lld's test suite relied on the previous "silently use last flag" semantics for its test suite: %lld always expanded to ld64.lld -platform_version macos 10.15 11.0 and tests that wanted a different value passed a 2nd -platform_version flag later on. But this now produces a warning if the platform passed to -platform_version is not macos. There weren't very many cases of this, so move these to use %no-arg-lld and manually pass -arch. Differential Revision: https://reviews.llvm.org/D124106 | 4 年前 | |
fix: allow linking with ABI compatible architectures for xcode 26.4 Signed-off-by: neilliuistaken <liujiajie12@huawei.com> | 2 个月前 | |
[lld-macho] Refactor archive loading The previous logic was duplicated between symbol-initiated archive loads versus flag-initiated loads (i.e. -force_load and -ObjC). This resulted in code duplication as well as redundant work -- we would create Archive instances twice whenever we had one of those flags; once in getArchiveMembers and again when we constructed the ArchiveFile. This was motivated by an upcoming diff where we load archive members containing ObjC-related symbols before loading those containing ObjC-related sections, as well as before performing symbol resolution. Without this refactor, it would be difficult to do that while avoiding loading the same archive member twice. Differential Revision: https://reviews.llvm.org/D108780 | 4 年前 | |
[lld-macho] Support --thinlto-jobs The test is loosely based off LLD-ELF's thinlto.ll. However, I found that test questionable because the the -save_temps behavior it checks for is identical regardless of whether we are running in single- or multi-threaded mode. I tried writing a test based on --time-trace but couldn't get it to run deterministically... so I've opted to just skip checking that behavior for now. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D99356 | 5 年前 | |
[lld-macho] Add time tracing for LTO The test is similar to the one used for LLD-ELF. Differential Revision: https://reviews.llvm.org/D99318 | 5 年前 | |
[lld-macho] Add support for --threads Code and test are largely identical to the LLD-ELF equivalents. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D99312 | 5 年前 | |
[lld, ELF and mac] Add --time-trace=<file>, remove --time-trace-file=<file> --time-trace=foo has the same behavior as --time-trace --time-trace-file=<file> had previously. Also, for mac, make --time-trace-granularity *not* imply --time-trace, to match behavior of the ELF port. Differential Revision: https://reviews.llvm.org/D128451 | 3 年前 | |
[lld/mac] Fix nondeterminism in output section ordering The two different thread_local_regular sections (__thread_data and more_thread_data) had nondeterminstic ordering for two reasons: 1. https://reviews.llvm.org/D102972 changed concatOutputSections from MapVector to DenseMap, so when we iterate it to make output segments, we would add the two sections to the __DATA output segment in nondeterministic order. 2. The same change also moved the two stable_sort()s for segments and sections to sort(). Since sections with assigned priority (such as TLV data) have the same priority for all sections, this is incorrect -- we must use stable_sort() so that the initial (input-order-based) order remains. As a side effect, we now (deterministically) put the __common section in front of __bss (while previously we happened to put it after it). (__common and __bss are both zerofill so both have order INT_MAX, but common symbols are added to inputSections before normal sections are collected.) Makes lld/test/MachO/tlv.s and lld/test/MachO/tlv-dylib.s pass with LLVM_ENABLE_EXPENSIVE_CHECKS=ON. Differential Revision: https://reviews.llvm.org/D105054 | 4 年前 | |
[lld-macho] Fix alignment of TLV data sections References from thread-local variable sections are treated as offsets relative to the start of the thread-local data memory area, which is initialized via copying all the TLV data sections (which are all contiguous). If later data sections require a greater alignment than earlier ones, the offsets of data within those sections won't be guaranteed to aligned unless we normalize alignments. We therefore use the largest alignment for all TLV data sections. Reviewed By: #lld-macho, int3 Differential Revision: https://reviews.llvm.org/D116263 | 4 年前 | |
[lld-macho][nfc] Clean up trailing spaces and tabs | 4 年前 | |
[lld-macho][test] Simplify --allow-empty with count 0 | 4 年前 | |
[lld-macho][nfc] Rename %no_fatal_warnings_lld in tests ... to use hyphens instead of underscores, making it consistent with our other substitutions like %no-arg-lld and %lld-watchos. Reviewed By: keith Differential Revision: https://reviews.llvm.org/D119513 | 4 年前 | |
[lld-macho][nfc] Add REQUIRES: x86 to test I didn't realize that llvm-objdump's features were arch-specific. This should fix the non-x86 buildbots. | 4 年前 | |
[test] Mark uuid.s as unsupported on Windows For systems using gnuwin32, awk does not exist. | 4 年前 | |
[llvm-objdump] Print memory operand addresses as regular comments The patch reuses the common code to print memory operand addresses as instruction comments. This helps to align the comments and enables using target-specific comment markers when evaluateMemoryOperandAddress() is implemented for them. Differential Revision: https://reviews.llvm.org/D104861 | 4 年前 | |
[lld/mac] Implement support for .weak_def_can_be_hidden I first had a more invasive patch for this (D101069), but while trying to get that polished for review I realized that lld's current symbol merging semantics mean that only a very small code change is needed. So this goes with the smaller patch for now. This has no effect on projects that build with -fvisibility=hidden (e.g. chromium), since these see .private_extern symbols instead. It does have an effect on projects that build with -fvisibility-inlines-hidden (e.g. llvm) in -O2 builds, where LLVM's GlobalOpt pass will promote most inline functions from .weak_definition to .weak_def_can_be_hidden. Before this patch: % ls -l out/gn/bin/clang out/gn/lib/libclang.dylib -rwxr-xr-x 1 thakis staff 113059936 Apr 22 11:51 out/gn/bin/clang -rwxr-xr-x 1 thakis staff 86370064 Apr 22 11:51 out/gn/lib/libclang.dylib % out/gn/bin/llvm-objdump --macho --weak-bind out/gn/bin/clang | wc -l 8291 % out/gn/bin/llvm-objdump --macho --weak-bind out/gn/lib/libclang.dylib | wc -l 5698 With this patch: % ls -l out/gn/bin/clang out/gn/lib/libclang.dylib -rwxr-xr-x 1 thakis staff 111721096 Apr 22 11:55 out/gn/bin/clang -rwxr-xr-x 1 thakis staff 85291208 Apr 22 11:55 out/gn/lib/libclang.dylib thakis@MBP llvm-project % out/gn/bin/llvm-objdump --macho --weak-bind out/gn/bin/clang | wc -l 725 thakis@MBP llvm-project % out/gn/bin/llvm-objdump --macho --weak-bind out/gn/lib/libclang.dylib | wc -l 542 Linking clang becomes a tiny bit faster with this patch: x 100 0.67263818 0.77847815 0.69430709 0.69877208 0.017715892 + 100 0.67209601 0.73323393 0.68600798 0.68917346 0.012824377 Difference at 95.0% confidence -0.00959861 +/- 0.00428661 -1.37364% +/- 0.613449% (Student's t, pooled s = 0.0154648) This only happens if lld with the patch and lld without the patch are both linked with an lld with the patch or both linked with an lld without the patch (...or with ld64). I accidentally linked the lld with the patch with an lld without the patch and the other way round at first. In that setup, no difference is found. That makese sense, since having fewer weak imports will make the linked output a bit faster too. So not only does this make linking binaries such as clang a bit faster (since fewer exports need to be written to the export trie by lld), the linked output binary binary is also a bit faster (since dyld needs to process fewer dynamic imports). This also happens to fix the one check-clang failure when using lld as host linker, but mostly for silly reasons: See crbug.com/1183336, mostly comment 26. The real bug here is that c-index-test links all of LLVM both statically and dynamically, which is an ODR violation. Things just happen to work with this patch. So after this patch, check-clang, check-lld, check-llvm all pass with lld as host linker :) Differential Revision: https://reviews.llvm.org/D101080 | 5 年前 | |
[lld-macho] Parse & emit the N_ARM_THUMB_DEF symbol flag Eventually we'll use this flag to properly handle bl/blx opcodes. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D101558 | 5 年前 | |
[lld-macho] Add --start-lib --end-lib In ld.lld, when an ObjFile/BitcodeFile is read in --start-lib state, the file is given archive semantics. --end-lib closes the previous --start-lib. A build system can use this feature as an alternative to archives. This patch ports the feature to lld-macho. --start-lib and --end-lib are positional, unlike usual ld64 options. I think the slight drawback does not matter as (a) reusing option names make build systems convenient (b) --start-lib a.o b.o --end-lib conveys more information than an alternative design: -objlib a.o -objlib b.o because --start-lib makes it clear which objects are in the same conceptual archive. This provides flexibility (c) -objlib/-filelist interaction may be weird. Close https://github.com/llvm/llvm-project/issues/52931 Reviewed By: #lld-macho, Jez Ng, oontvoo Differential Revision: https://reviews.llvm.org/D116913 | 4 年前 | |
[lld-macho] Stop crash when emitting personalities with -dead_strip The <internal> symbol was tripping an assertion in getVA() because it was not marked as used. Per the comment above that symbols creation, dead stripping has already occurred so marking this symbol as used is accurate. Fixes https://github.com/llvm/llvm-project/issues/55565 Differential revision: https://reviews.llvm.org/D126072 | 4 年前 | |
[lld/mac] Resolve defined symbols before undefined symbols Ports https://reviews.llvm.org/D95985 to the MachO port. Happens to fix PR51135; see that bug for details. Also makes lld's behavior match ld64 for the included test case. Differential Revision: https://reviews.llvm.org/D106293 | 4 年前 | |
[lld/mac] Remove unused -L%t flags from tests No behavior change. Differential Revision: https://reviews.llvm.org/D101623 | 5 年前 | |
[lld/mac] Remove unused -L%t flags from tests No behavior change. Differential Revision: https://reviews.llvm.org/D101623 | 5 年前 | |
[lld-macho][nfc] Clean up tests * Migrate most of our tests to use split-file instead of echo * Remove individual rm -f %t/libfoo.a commands in favor of a top-level rm -rf %t * Remove unused Inputs/libfunction.s Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D93604 | 5 年前 | |
[lld-macho][NFC] Purge stale test-output trees prior to split-file Enforce standard practice Differential Revision: https://reviews.llvm.org/D102112 | 5 年前 | |
[lld-macho][nfc] Clean up trailing spaces and tabs | 4 年前 | |
[lld/mac] slightly improve weak-private-extern.s test - __got is in --bind output, so print that too (makes the test a bit stronger) - WEAK_DEFINES, BINDS_TO_WEAK are in the mach-o header, so --private-header is enough, no need for --all-headers (makes the test a bit easier to work with when it fails) Differential Revision: https://reviews.llvm.org/D101065 | 5 年前 | |
[lld-macho][nfc] Convert tabs to spaces | 5 年前 | |
[lld-macho] Implement -why_live (without perf overhead) This was based off @thakis' draft in {D103517}. I employed templates to ensure the support for -why_live wouldn't slow down the regular non-why-live code path. No stat sig perf difference on my 3.2 GHz 16-Core Intel Xeon W: base diff difference (95% CI) sys_time 1.195 ± 0.015 1.199 ± 0.022 [ -0.4% .. +1.0%] user_time 3.716 ± 0.022 3.701 ± 0.025 [ -0.7% .. -0.1%] wall_time 4.606 ± 0.034 4.597 ± 0.046 [ -0.6% .. +0.2%] samples 44 37 Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D120377 | 4 年前 | |
[lld-macho][nfc] Clean up tests * Remove unnecessary rm -rf %ts * Have lc-linker-option.ll use the right comment marker | 5 年前 | |
[llvm-objdump] Print memory operand addresses as regular comments The patch reuses the common code to print memory operand addresses as instruction comments. This helps to align the comments and enables using target-specific comment markers when evaluateMemoryOperandAddress() is implemented for them. Differential Revision: https://reviews.llvm.org/D104861 | 4 年前 | |
[llvm-objdump] Print memory operand addresses as regular comments The patch reuses the common code to print memory operand addresses as instruction comments. This helps to align the comments and enables using target-specific comment markers when evaluateMemoryOperandAddress() is implemented for them. Differential Revision: https://reviews.llvm.org/D104861 | 4 年前 | |
[lld-macho] Make everything PIE by default Modern versions of macOS (>= 10.7) and in general all modern Mach-O target archs want PIEs by default. ld64 defaults to PIE for iOS >= 4.3, as well as for all versions of watchOS and simulators. Basically all the platforms LLD is likely to target want PIE. So instead of cluttering LLD's code with legacy version checks, I think it's simpler to just default to PIE for everything. Note that -no_pie still works, so users can still opt out of it. Reviewed By: #lld-macho, thakis, MaskRay Differential Revision: https://reviews.llvm.org/D101513 | 5 年前 | |
[lld-macho] Implement cstring deduplication Our implementation draws heavily from LLD-ELF's, which in turn delegates its string deduplication to llvm-mc's StringTableBuilder. The messiness of this diff is largely due to the fact that we've previously assumed that all InputSections get concatenated together to form the output. This is no longer true with CStringInputSections, which split their contents into StringPieces. StringPieces are much more lightweight than InputSections, which is important as we create a lot of them. They may also overlap in the output, which makes it possible for strings to be tail-merged. In fact, the initial version of this diff implemented tail merging, but I've dropped it for reasons I'll explain later. **Alignment Issues** Mergeable cstring literals are found under the __TEXT,__cstring section. In contrast to ELF, which puts strings that need different alignments into different sections, clang's Mach-O backend puts them all in one section. Strings that need to be aligned have the .p2align directive emitted before them, which simply translates into zero padding in the object file. I *think* ld64 extracts the desired per-string alignment from this data by preserving each string's offset from the last section-aligned address. I'm not entirely certain since it doesn't seem consistent about doing this; but perhaps this can be chalked up to cases where ld64 has to deduplicate strings with different offset/alignment combos -- it seems to pick one of their alignments to preserve. This doesn't seem correct in general; we can in fact can induce ld64 to produce a crashing binary just by linking in an additional object file that only contains cstrings and no code. See PR50563 for details. Moreover, this scheme seems rather inefficient: since unaligned and aligned strings are all put in the same section, which has a single alignment value, it doesn't seem possible to tell whether a given string doesn't have any alignment requirements. Preserving offset+alignments for strings that don't need it is wasteful. In practice, the crashes seen so far seem to stem from x86_64 SIMD operations on cstrings. X86_64 requires SIMD accesses to be 16-byte-aligned. So for now, I'm thinking of just aligning all strings to 16 bytes on x86_64. This is indeed wasteful, but implementation-wise it's simpler than preserving per-string alignment+offsets. It also avoids the aforementioned crash after deduplication of differently-aligned strings. Finally, the overhead is not huge: using 16-byte alignment (vs no alignment) is only a 0.5% size overhead when linking chromium_framework. With these alignment requirements, it doesn't make sense to attempt tail merging -- most strings will not be eligible since their overlaps aren't likely to start at a 16-byte boundary. Tail-merging (with alignment) for chromium_framework only improves size by 0.3%. It's worth noting that LLD-ELF only does tail merging at -O2. By default (at -O1), it just deduplicates w/o tail merging. @thakis has also mentioned that they saw it regress compressed size in some cases and therefore turned it off. ld64 does not seem to do tail merging at all. **Performance Numbers** CString deduplication reduces chromium_framework from 250MB to 242MB, or about a 3.2% reduction. Numbers for linking chromium_framework on my 3.2 GHz 16-Core Intel Xeon W: N Min Max Median Avg Stddev x 20 3.91 4.03 3.935 3.95 0.034641016 + 20 3.99 4.14 4.015 4.0365 0.0492336 Difference at 95.0% confidence 0.0865 +/- 0.027245 2.18987% +/- 0.689746% (Student's t, pooled s = 0.0425673) As expected, cstring merging incurs some non-trivial overhead. When passing --no-literal-merge, it seems that performance is the same, i.e. the refactoring in this diff didn't cost us. N Min Max Median Avg Stddev x 20 3.91 4.03 3.935 3.95 0.034641016 + 20 3.89 4.02 3.935 3.9435 0.043197831 No difference proven at 95.0% confidence Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D102964 | 4 年前 | |
[llvm-objdump][MachO] Print a newline before lazy bind/bind/weak/exports trie This adds a separator between two pieces of information. Reviewed By: #lld-macho, alexshap Differential Revision: https://reviews.llvm.org/D102114 | 5 年前 | |
[lld-macho] Handle user-provided dtrace symbols to avoid linking failure This fixes https://github.com/llvm/llvm-project/issues/56238. ld64.lld currently does not generate __dof section in Mach-O, and -no_dtrace_dof option is on by default. However when there are user-defined dtrace symbols, ld64.lld will treat them as undefined symbols, which causes the linking to fail because lld cannot find their definitions. This patch allows ld64.lld to rewrite the instructions calling dtrace symbols to instructions like nop as what ld64 does; therefore, when encountered with user-provided dtrace probes, the linking can still succeed. I'm not sure whether support for dtrace is expected in lld, so for now I didn't add codes to make lld emit __dof section like ld64, and only made it possible to link with dtrace symbols provided. If this feature is needed, I can add that part in Dtrace.cpp & Dtrace.h. Reviewed By: int3, #lld-macho Differential Revision: https://reviews.llvm.org/D129062 | 3 年前 | |
[lld/mac] Support writing zippered dylibs and bundles With -platform_version flags for two distinct platforms, this writes a LC_BUILD_VERSION header for each. The motivation is that this is needed for self-hosting with lld as linker after D124059. To create a zippered output at the clang driver level, pass -target arm64-apple-macos -darwin-target-variant arm64-apple-ios-macabi to create a zippered dylib. (In Xcode's clang, -darwin-target-variant is spelled just -target-variant.) (If you pass -target arm64-apple-ios-macabi -target-variant arm64-apple-macos instead, ld64 crashes!) This results in two -platform_version flags being passed to the linker. ld64 also verifies that the iOS SDK version is at least 13.1. We don't do that yet. But ld64 also does that for other platforms and we don't. So we need to do that at some point, but not in this patch. Only dylib and bundle outputs can be zippered. I verified that a Catalyst app linked against a dylib created with clang -shared foo.cc -o libfoo.dylib \ -target arm64-apple-macos \ -target-variant arm64-apple-ios-macabi \ -Wl,-install_name,@rpath/libfoo.dylib \ -fuse-ld=$PWD/out/gn/bin/ld64.lld runs successfully. (The app calls a function f() in libfoo.dylib that returns a const char* "foo", and NSLog(@"%s")s it.) ld64 is a bit more permissive when writing zippered outputs, see references to "unzippered twins". That's not implemented yet. (If anybody wants to implement that, D124275 is a good start.) Differential Revision: https://reviews.llvm.org/D124887 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 8 个月前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 2 个月前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 4 年前 |