[lld-macho] Skip platform checks for a few libSystem re-exportsXCode 12 ships with mismatched platforms for these libraries,so this hack is necessary...Fixes PR49799.Reviewed By: #lld-macho, g
[lld-macho] Skip platform checks for a few libSystem re-exportsXCode 12 ships with mismatched platforms for these libraries,so this hack is necessary...Fixes PR49799.Reviewed By: #lld-macho, gkm, smeenaiDifferential Revision: https://reviews.llvm.org/D100913
show more ...
[lld-macho] Only codesign by default on arm64 macOSinstead of doing it on all arm64 platforms.Reviewed By: #lld-macho, gkmDifferential Revision: https://reviews.llvm.org/D98446
[lld-macho] Fix & fold reexport-nested-libs test into stub-link.sThe reexport-nested-libs test added in D97438 was a bit wonky.First, it was linking against libReexportSystem.tbd which targets th
[lld-macho] Fix & fold reexport-nested-libs test into stub-link.sThe reexport-nested-libs test added in D97438 was a bit wonky.First, it was linking against libReexportSystem.tbd which targets theiOS simulator, and which in turn attempted to re-export the iOSsimulator's libSystem. However, due to the way `-syslibroot` works, itwas actually re-exporting the macOS libSystem.As a result, the test was not actually able to resolve the symbols inthe desired libSystem. I'm guessing that @oontvoo was confused by thisand therefore included those symbols in libReexportSystem.tbd itself.But this means that the test wasn't actually testing the resolution ofre-exported symbols (though it did at least verify that the re-exportedlibraries could be located).After some consideration, I figured that stub-link.s could be extendedto cover what reexport-nested-libs.s was attempting to do. The testtargets macOS, so we only have one `-syslibroot` and no chance ofconfusion.Reviewed By: #lld-macho, oontvooDifferential Revision: https://reviews.llvm.org/D97866
[lld-macho] Change loadReexport to handle the case where a TAPI re-exports to reference documents nested within other TBD.Currently, it was delibrately impleneted to not handle this case, but as it
[lld-macho] Change loadReexport to handle the case where a TAPI re-exports to reference documents nested within other TBD.Currently, it was delibrately impleneted to not handle this case, but as it has turnt out, we need this feature.The concrete use case is `System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa` reexports /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit , which then rexports /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundationThe current implemention uses a global currentTopLevelTapi, which is not reset until it finishes loading the whole tree.This is a problem because if the top-level is set to Cocoa, then when we get to UIFoundation, it will try to find UIFoundation in the current top level, which is Cocoa and will not find it.The right thing should be: - When loading a library from a TBD file, re-exports need to be looked up in the auxiliary documents within the same TBD. - When loading from an actual dylib, no additional TBD documents need to be examined. - In no case does a re-export mentioned in one TBD file need to be looked up in a document in an auxiliary document from a different TBD fileDifferential Revision: https://reviews.llvm.org/D97438
[lld/mac] Use libSystem.dylib instead of libSystem.B.dylib in testsFor -flat_namespace, lld needs to load dylibs in LC_LOAD_DYLIB.The current setup meant that libSystem.dylib would cause a LC_LOAD
[lld/mac] Use libSystem.dylib instead of libSystem.B.dylib in testsFor -flat_namespace, lld needs to load dylibs in LC_LOAD_DYLIB.The current setup meant that libSystem.dylib would cause a LC_LOAD_DYLIBwith libSystem.B.dylib, but that didn't exist in our libsysroot fortests. So just drop the .B.See https://reviews.llvm.org/D97641#2595237 andhttps://reviews.llvm.org/D97641#2595270
[lld-macho] Disable invalid/stub-link.s test for MacIt seems to be failing on some Google Buildbots.This diff also includes a minor fix for the install name of one oflibSystem's re-exports. I do
[lld-macho] Disable invalid/stub-link.s test for MacIt seems to be failing on some Google Buildbots.This diff also includes a minor fix for the install name of one oflibSystem's re-exports. I don't think it's the cause of the testfailure, though. The wrong install name just meant that the symbollookup failure would still happen, but it would have been caused by there-export not being found, instead of the arch failing to match.Differential Revision: https://reviews.llvm.org/D86728
[lld-macho] Handle TAPI and regular re-exports uniformlyThe re-exports list in a TAPI document can either refer to other inlinedTAPI documents, or to on-disk files (which may themselves be TBD or
[lld-macho] Handle TAPI and regular re-exports uniformlyThe re-exports list in a TAPI document can either refer to other inlinedTAPI documents, or to on-disk files (which may themselves be TBD orregular files.) Similarly, the re-exports of a regular dylib can referto a TBD file.Differential Revision: https://reviews.llvm.org/D85404
lld: initial pass at supporting TBDAdd support to lld to use Text Based API stubs for linking. This issupport is incomplete not filtering out platforms. It also does notaccount for architecture
lld: initial pass at supporting TBDAdd support to lld to use Text Based API stubs for linking. This issupport is incomplete not filtering out platforms. It also does notaccount for architecture specific API handling and potentially does notcorrectly handle trees of re-exports with inlined libraries beingtreated as direct children of the top level library.