aprantl added a comment. Thanks, Pavel, these are all very valid concerns and in retrospect I should have at least slapped an RFC label on this before dumping into phabricator last night. The goal of this (and I should have mentioned that in the description) is to make the Xcode SDK something that behaves more like the compiler's resource directory, as in that it ships with LLDB rather than with the debugged program. This important primarily for importing Swift and Clang modules in the expression evaluator, and getting at the APINotes from the SDK in Swift.
For a cross-debugging scenario, this means you have to have an SDK for your target installed alongside LLDB. In Xcode this will always be the case. As you correctly identified my first patch does not work if you are cross debugging, e.g., a macOS target from a Linux machine because we are querying the HostPlatform for the SDK path and only PlatformDarwin implements this function. I'm open to any suggestions (and will also think about this myself) for how to make the layering less awkward, the only hard requirement I have is that I need the SDK path remapping information inside the per-module Swift typesystem, so I can't depend on a target for any of this. What do you think about the general idea of a HostPlatform having several cross-SDKs installed and knowing where to find them? What would be a better place for this otherwise? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D76471/new/ https://reviews.llvm.org/D76471 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
