[Lldb-commits] [PATCH] D76471: Remap the target SDK directory to the host SDK directory

Wed Apr 1 16:21:18 PDT 2020

aprantl added a comment.

In D76471#1954205 <https://reviews.llvm.org/D76471#1954205>, @labath wrote:

> I don't think that spreading this out over host and platform is convoluted. In fact, I was going to propose something like that myself. However, it does bring us back to the question of the "linux" sdk.
>
> A couple of comments ago you said:
>
> > The "Linux" SDK is a placeholder of sorts when debugging a Swift-on-Linux server application (e.g., something like https://www.kitura.io/) from *within* Xcode that points to a directory that contains the Swift resources/stdlib cross-compiled for Linux.
>
> When you say "cross-compiled", I am imagining that the resulting binary will be a regular linux elf file, and it's triple will be detected as `***-linux`. So, `Platform::GetPlatformForArchitecture(GetArchitecture(), nullptr)` will return PlatformLinux, and the subsequent `GetSDKPath` will return blank, whereas I am expecting that you would want it to return `HostInfoMacOSX::GetXcodeSDK(linux)` (if running on macos).
>
> So, if all of this is true, and we want this interface to reside on the Platform class, then I think the implementation of `GetSDKPath` needs to be spread out over the individual platform classes, which would delegate to the appropriate host api. E.g. `PlatformLinux::GetSDKPath` (with no arguments) would be implemented via `HostInfo::GetXcodeSDK(linux)`, `PlatformRemoteAppleWatch::GetSDKPath` as `HostInfo::GetXcodeSDK(watchos)`, etc.
>
> This would give us maximum flexibility. For instance one could implement `HostInfoLinux::GetXcodeSDK` to locate the xcode sdk through some other mechanism, and then cross-debugging mac binaries would work too. Or, one could implement `PlatformXXX::GetSDKPath` to download the sdk from the remote system somehow if it is not found on the host, and then we would be able to debug on any host. However, I found all of these scenarios fairly unlikely, which is why I said that going straight for the host seems fine. The interface is still sensible -- we just say that the host system has to provide the sdks for any of the listed platforms. And if the host doesn't provide that, tough luck. That setup can always be generalized if we have a need for it.

Great! I think the current version of the patch reflects all of that, with only one difference — something that I actually overlooked in the previous version. We now have Platform that provides the interface to provide an SDK, and will forward the question to Host. Each Host can define its own mechanisms for doing so. So far I have only provided an implementation for macOS, which runs `xcrun`. What I can't do is remove the SDK parameter from the interface in platform, because Xcode may contain differently versioned SDKs (e.g., a MacOSX10.14.sdk and a MacOSX10.15.sdk) plus some wrinkles that are only relevant when you are developing the OS itself. That said, even without removing the SDK parameter from GetSDKPath(), we can still implement HostInfoLinux::GetXcodeSDK() for hypothetical Linux -> macOS cross-debugger you mentioned above, so I don't think the extra parameter tarnishes the design.

> In D76471#1954045 <https://reviews.llvm.org/D76471#1954045>, @JDevlieghere wrote:
> 
>> I think the current separation makes a lot of sense, but I don't like that XcodeSDK class is part of Utility. I understand the need from a layering perspective and I don't really have a better idea, but maybe someone else does?
> 
> We could move it up to Host, and have it be next to the HostInfo::GetXcodeSDK function which returns it. Would that look any better?

In a way XcodeSDK is like Triple or ArchSpec, so I've started to feel less bad about putting it into Utility, where ArchSpec lives.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76471/new/

https://reviews.llvm.org/D76471