| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lld-macho] Avoid infinite recursion when parsing corrupted export tries (#152569) If an export trie is encoded incorrectly, and one of the children offsets points back to one of the nodes earlier in the serialization, the current code will end up in an infinite recursion, and eventually fail exhausting the available memory. The failure can be avoided if, before recursing, one checks that the offset is valid, that is, that the offset is beyond the current position. This is similar to a check done by llvm-objdump which reports the trie being corrupted. | 11 个月前 | |
[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] Don't assert during thunk insertion if there are undefined symbols We end up calling resolveBranchVA(), which asserts for Undefineds. As fix, just return early in Writer::run() if there are any diagnostics after processing relocations (which is where undefined symbol errors are emitted). This matches what the ELF port does. Differential Revision: https://reviews.llvm.org/D109079 | 4 年前 | |
[lld-macho] Diagnose unaligned arm64 PAGEOFF12 relocations The LDR and STR instructions store their immediate offsets as a multiple of the load/store's size. Therefore, if the target address is not aligned, the relocation is not representable. We now emit an error if that happens, similarly to ld64. This commit removes a test case from loh-adrp-ldr.s that contained an unaligned LDR. Differential Revision: https://reviews.llvm.org/D133269 | 3 年前 | |
[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] 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] Include address offsets in error messages This makes it easier to pinpoint the source of the problem. TODO: Have more relocation error messages make use of this functionality. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D118798 | 4 年前 | |
[lld-macho] Include address offsets in error messages This makes it easier to pinpoint the source of the problem. TODO: Have more relocation error messages make use of this functionality. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D118798 | 4 年前 | |
[lld][macho] Error out gracefully when offset is outside literal section (#164660) We typically shouldn't get this, but when we do (e.g. in #139439) we should error out gracefully instead of crashing. Note that we are stricter than ld64 here; ld64 appears to be able to handle section offsets that point outside literal sections if the end result is a valid pointer to another section in the input object file. Supporting this would probably be a pain given our current design, and it seems like enough of an edge case that it's onot worth it. | 9 个月前 | |
[lld-macho][nfc] Convert tabs to spaces | 5 年前 | |
[lld-macho][nfc] Convert tabs to spaces | 5 年前 | |
[lld-macho] Include address offsets in error messages This makes it easier to pinpoint the source of the problem. TODO: Have more relocation error messages make use of this functionality. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D118798 | 4 年前 | |
[lld-macho] Associate compact unwind entries with function symbols Compact unwind entries (CUEs) contain pointers to their respective function symbols. However, during the link process, it's far more useful to have pointers from the function symbol to the CUE than vice versa. This diff adds that pointer in the form of Defined::compactUnwind. In particular, when doing dead-stripping, we want to mark CUEs live when their function symbol is live; and when doing ICF, we want to dedup sections iff the symbols in that section have identical CUEs. In both cases, we want to be able to locate the symbols within a given section, as well as locate the CUEs belonging to those symbols. So this diff also adds InputSection::symbols. The ultimate goal of this refactor is to have ICF support dedup'ing functions with unwind info, but that will be handled in subsequent diffs. This diff focuses on simplifying -dead_strip -- findFunctionsWithUnwindInfo is no longer necessary, and Defined::isLive() is now a lot simpler. Moreover, UnwindInfoSection no longer has to check for dead CUEs -- we simply avoid adding them in the first place. Additionally, we now support stripping of dead LSDAs, which follows quite naturally since markLive() can now reach them via the CUEs. Reviewed By: #lld-macho, gkm Differential Revision: https://reviews.llvm.org/D109944 | 4 年前 | |
Reapply "[lld] enable fixup chains by default (#79894)" (#99255) This reverts commit f55b79f59a77b4be586d649e9ced9f8667265011. The known issues with chained fixups have been addressed by #98913, #98305, #97156 and #95171. Compared to the original commit, support for xrOS (which postdates chained fixups' introduction) was added and an unnecessary test change was removed. ---------- Original commit message: Enable chained fixups in lld when all platform and version criteria are met. This is an attempt at simplifying the logic used in ld 907: https://github.com/apple-oss-distributions/ld64/blob/93d74eafc37c0558b4ffb88a8bc15c17bed44a20/src/ld/Options.cpp#L5458-L5549 Some changes were made to simplify the logic: - only enable chained fixups for macOS from 13.0 to avoid the arch check - only enable chained fixups for iphonesimulator from 16.0 to avoid the arch check - don't enable chained fixups for not specifically listed platforms - don't enable chained fixups for arm64_32 | 2 年前 | |
Reland "D144999 [MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs." Reasons for rolling forward: - the crash reported from Chromium was fixed in D151824 (not related to this patch at all) - since D152824 was committed, it should now be safe to roll this forward. New change: - add an additional _ in name check This reverts commit 4980eead4d0b4666d53dad07afb091375b3a13a0. | 3 年前 | |
[lld-macho] Mark local personality functions as INDIRECT_SYMBOL_LOCAL (#95171) This expands on the fix in 4e572db. The issue is pretty similar: we might put symbols in the GOT which don't need run-time binding, locally defined personality symbols in this case. We should set their indirect symbol table entries to INDIRECT_SYMBOL_LOCAL to help strip remove these local names from the symbol table. Checking if the symbol is private-extern doesn't cover all cases; it can also be a non-weak extern function too, for instance; use the needsBinding() helper to determine it. This was the case for the personality function in statically linked Rust executables. The extra non-LOCAL symbols triggered a bug in Apple's strip implementation. As the indirect value for the personality function was not set to the flag, but the symbol didn't require binding, it tried to make the symbol local, overwriting the GOT entry with the function's address in the process. This normally wouldn't be a problem, but if chained fixups are used, the fixup also encodes the offset to the next fixup, and it effectively zeroed this offset out, causing the remaining relocations on the page to not be performed by dyld. This caused the crash in https://issues.chromium.org/issues/325410295 The change in tests is a bit ugly, as a lot of symbol information is now removed by turning more symbols LOCAL. | 2 年前 | |
[lld-macho] Don't support relocations in cstring sections We can technically handle them, but since they shouldn't come up in any real-world programs (since ld64 dedups strings unconditionally), there's no reason to support them. It's a thoroughly untested code path too -- as evidenced by the fact that the only test this change breaks is one that verifies that we reject relocations when dedup'ing. There is no test that covers the case where we handle relocations in cstring sections when dedup is disabled. Reviewed By: #lld-macho, oontvoo, keith, thakis Differential Revision: https://reviews.llvm.org/D141025 | 3 年前 | |
[lld-macho][nfc] Give every SyntheticSection a fake InputSection Previously, it was difficult to write code that handled both synthetic and regular sections generically. We solve this problem by creating a fake InputSection at the start of every SyntheticSection. This refactor allows us to handle DSOHandle like a regular Defined symbol (since Defined symbols must be attached to an InputSection), and paves the way for supporting __mh_*header symbols. Additionally, it simplifies our binding/rebase code. I did have to extend Defined a little -- it now has a linkerInternal flag, to indicate that ___dso_handle should not be in the final symbol table. I've also added some additional testing for ___dso_handle. Reviewed By: #lld-macho, oontvoo Differential Revision: https://reviews.llvm.org/D98545 | 5 年前 | |
[lld-macho] Use source information in duplicate symbol errors Similarly to how undefined symbol diagnostics were changed in D128184, we now show where in the source file duplicate symbols are defined at: ld64.lld: error: duplicate symbol: _foo >> defined in bar.c:42 >> /path/to/bar.o >> defined in baz.c:1 >> /path/to/libbaz.a(baz.o) For objects that don't contain DWARF data, the format is unchanged. A slight difference to undefined symbol diagnostics is that we don't print the name of the symbol on the third line, as it's already contained on the first line. Differential Revision: https://reviews.llvm.org/D128425 | 4 年前 | |
[lld-macho] Basic support for linkage and visibility attributes in LTO When parsing bitcode, convert LTO Symbols to LLD Symbols in order to perform resolution. The "winning" symbol will then be marked as Prevailing at LTO compilation time. This is similar to what the other LLD ports do. This change allows us to handle linkonce symbols correctly, and to deal with duplicate bitcode symbols gracefully. Previously, both scenarios would result in an assertion failure inside the LTO code, complaining that multiple Prevailing definitions are not allowed. While at it, I also added basic logic around visibility. We don't do anything useful with it yet, but we do check that its value is valid. LLD-ELF appears to use it only to set FinalDefinitionInLinkageUnit for LTO, which I think is just a performance optimization. From my local experimentation, the linker itself doesn't seem to do anything differently when encountering linkonce / linkonce_odr / weak / weak_odr. So I've only written a test for one of them. LLD-ELF has more, but they seem to mostly be testing the intermediate bitcode output of their LTO backend...? I'm far from an expert here though, so I might very well be missing things. Reviewed By: #lld-macho, MaskRay, smeenai Differential Revision: https://reviews.llvm.org/D94342 | 5 年前 | |
[lld/mac] With -demangle, strip leading _ from non-mangled names For void f(); int main() { f(); } lld -demangle now produces ld64.lld: error: undefined symbol: f >>> referenced by path/to/main.o:(symbol main+0x8) instead of ld64.lld: error: undefined symbol: _f >>> referenced by path/to/main.o:(symbol _main+0x8) previously. (Without -demangle, it still prints _f and _main.) This does *not* match ld64's behavior, but it does match e.g. lld/COFF's behaviour. This is arguably easier to understand: clang prepends symbol names with _ on macOS, so it seems friendly if the linker removes it again in its diagnostics. It also makes the extern "C" insertion diagnostics we added recently look more self-consistent. Differential Revision: https://reviews.llvm.org/D135189 | 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 | 4 年前 | |
[lld-macho] Avoid infinite recursion when parsing corrupted export tries (#152569) If an export trie is encoded incorrectly, and one of the children offsets points back to one of the nodes earlier in the serialization, the current code will end up in an infinite recursion, and eventually fail exhausting the available memory. The failure can be avoided if, before recursing, one checks that the offset is valid, that is, that the offset is beyond the current position. This is similar to a check done by llvm-objdump which reports the trie being corrupted. | 11 个月前 | |
[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] Remove duplicate minimum version info At some point PlatformInfo's Target changed types to a type that also has minimum deployment target info. This caused ambiguity if you tried to get the target triple from the Target, as the actual minimum version info was being stored separately. This bulk of this change is changing the parsing of these values to support this. Differential Revision: https://reviews.llvm.org/D145263 | 3 年前 | |
[lld-macho] Remove symbols to __mod_init_func with -init_offsets (#97156) When -fixup_chains/-init_offsets is used, a different section, __init_offsets is synthesized from __mod_init_func. If there are any symbols defined inside __mod_init_func, they are added to the symbol table unconditionally while processing the input files. Later, when querying these symbols' addresses (when constructing the symtab or exports trie), we crash with a null deref, as there is no output section assigned to them. Just making the symbols point to __init_offsets is a bad idea, as the new section stores 32-bit integers instead of 64-bit pointers; accessing the symbols would not do what the programmer intended. We should entirely omit them from the output. This is what ld64 and ld-prime do. This patch uses the same mechanism as dead-stripping to mark these symbols as not needed in the output. There might be nicer fixes than the workaround, this is discussed in #97155. Fixes https://github.com/llvm/llvm-project/pull/79894#issuecomment-1944092892 Fixes #94716 | 2 年前 | |
[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] 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] 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] Standardize error messages Errors / warnings that originate from a particular file should be of the form $file: $message. Reviewed By: #lld-macho, keith Differential Revision: https://reviews.llvm.org/D140634 | 3 年前 | |
[lld] Fix test failures when running as root user (#81339) This makes it easier to run the tests in a containerized environment. | 2 年前 | |
[lld][macho] Support 1-byte branch relocs for x86_64 (#164439) | 9 个月前 | |
[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 年前 | |
Reland "[TextAPI] Implement TBDv5 Reader" Introduce initial reader for TBDv5 which is in JSON. This captures all the currently understood fields within the internal structure InterfaceFile. New fields will be followed up in future PRs. Reviewed By: pete Differential Revision: https://reviews.llvm.org/D144156 | 3 年前 | |
[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] 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] Remove linking bitcode support Apple deprecated bitcode in the deployment process in Xcode 14.0. Last month Apple started requiring Xcode 14.1+ to submit apps to the App Store. Since there isn't a use for bundling bitcode outside of submitting to the App Store we should be safe to delete this handling entirely from LLD. Differential Revision: https://reviews.llvm.org/D150697 | 3 年前 | |
[test] Use host platform specific error message substitution in lit tests On z/OS, the following error message is not matched correctly in lit tests. EDC5129I No such file or directory. This patch uses a lit config substitution to check for platform specific error messages. Reviewed By: muiez, jhenderson Differential Revision: https://reviews.llvm.org/D95246 | 5 年前 | |
[lld-macho] Standardize error messages Errors / warnings that originate from a particular file should be of the form $file: $message. Reviewed By: #lld-macho, keith Differential Revision: https://reviews.llvm.org/D140634 | 3 年前 | |
[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] Basic support for linkage and visibility attributes in LTO When parsing bitcode, convert LTO Symbols to LLD Symbols in order to perform resolution. The "winning" symbol will then be marked as Prevailing at LTO compilation time. This is similar to what the other LLD ports do. This change allows us to handle linkonce symbols correctly, and to deal with duplicate bitcode symbols gracefully. Previously, both scenarios would result in an assertion failure inside the LTO code, complaining that multiple Prevailing definitions are not allowed. While at it, I also added basic logic around visibility. We don't do anything useful with it yet, but we do check that its value is valid. LLD-ELF appears to use it only to set FinalDefinitionInLinkageUnit for LTO, which I think is just a performance optimization. From my local experimentation, the linker itself doesn't seem to do anything differently when encountering linkonce / linkonce_odr / weak / weak_odr. So I've only written a test for one of them. LLD-ELF has more, but they seem to mostly be testing the intermediate bitcode output of their LTO backend...? I'm far from an expert here though, so I might very well be missing things. Reviewed By: #lld-macho, MaskRay, smeenai Differential Revision: https://reviews.llvm.org/D94342 | 5 年前 | |
[lld-macho] Fix symbol name returned from InputSection::getLocation This commit fixes the issue that getLocation always printed the name of the first symbol in the section. For clarity, upper_bound is used instead of a linear search for finding the closest symbol name. Note that this change does not affect performance: this function is only called when printing errors and symbols typically contains a single symbol because of .subsections_via_symbols. Differential Revision: https://reviews.llvm.org/D127670 | 4 年前 | |
[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] Convert a test to use 'target=...' instead of triple check Part of the project to eliminate special handling for triples in lit expressions. | 3 年前 | |
Reland "[lld-macho] Show source information for undefined references" The error used to look like this: ld64.lld: error: undefined symbol: _foo >>> referenced by /path/to/bar.o:(symbol _baz+0x4) If DWARF line information is available, we now show where in the source the references are coming from: ld64.lld: error: unreferenced symbol: _foo >>> referenced by: bar.cpp:42 (/path/to/bar.cpp:42) >>> /path/to/bar.o:(symbol _baz+0x4) The reland is identical to the first time this landed. The fix was in D128294. This reverts commit 0cc7ad417585b3185c32e395cc5e6cf082a347af. Differential Revision: https://reviews.llvm.org/D128184 | 4 年前 | |
Reland "[lld-macho] Group undefined symbol diagnostics by symbol". This reverts commit 36e7c9a450db5e22af1ec21412d918ceb2313942. This relands d61341768cf0cff7c with the fix described in https://reviews.llvm.org/D127753#3587390 | 4 年前 | |
[lld/mac] With -demangle, strip leading _ from non-mangled names For void f(); int main() { f(); } lld -demangle now produces ld64.lld: error: undefined symbol: f >>> referenced by path/to/main.o:(symbol main+0x8) instead of ld64.lld: error: undefined symbol: _f >>> referenced by path/to/main.o:(symbol _main+0x8) previously. (Without -demangle, it still prints _f and _main.) This does *not* match ld64's behavior, but it does match e.g. lld/COFF's behaviour. This is arguably easier to understand: clang prepends symbol names with _ on macOS, so it seems friendly if the linker removes it again in its diagnostics. It also makes the extern "C" insertion diagnostics we added recently look more self-consistent. Differential Revision: https://reviews.llvm.org/D135189 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 11 个月前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 9 个月前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 11 个月前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 9 个月前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 |