labath added a comment. Thanks for the explanation. I have some ideas on this below, though I am not sure if I know enough about the problem to be able to tell which ones are feasible.
In D76471#1933923 <https://reviews.llvm.org/D76471#1933923>, @aprantl wrote: > 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? I don't think putting this knowledge inside the host platform instance is a good idea. It already seems very odd to be enumerating all darwin platforms inside PlatformDarwin, when there is already PlatformXXX class for each of these platforms. It would be even weirder to include non-darwin platforms there. Technically, platform objects are not tied to any particular target, and all you need to get one is an ArchSpec (`static Platform::GetPlatformForArchitecture`). Putting this knowledge into the "right" platform instances and then finding them based on the module's ArchSpec seems like it should be possible. I'm not convinced its a good idea to reach for a Platform object from a Module (it seems to open possibilities for inconsistencies between the platform chosen in this way, and the platform used for eventual launches), but it definitely seems better than defaulting to the host platform object (which also doesn't do anything to address the inconsistency). Alternatively, since the list of "sdk" that the lldb happens to come with is a property of how it is built/deployed, it may also make sense to put this logic into the Host module somehow. A combination of the two approaches might be interesting too (the interactions between host and platform are always a bit weird). E.g., we could still query the Platform object for the sdk, but it would defer to some Host functionality to produce the right value. That way we could use `xcrun` (or whatever) on a mac, but theoretically other host systems could implement a different mechanism to locate the mac SDKs. Finally, it may be possible to just have the list of sdks as some hardcoded list (populated by the build system?), in which case the code for that could live just about anywhere... 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
