When debugging a remote platform, the platform you get from
GetPlatformForArchitecture doesn't inherit from PlatformDarwin.
HostInfoMacOSX seems like the right place to have a global store of
local paths.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM modulo the inline comment.
lldb/include/lldb/Host/HostInfoBase.h | ||
---|---|---|
96 | This should probably be named GetXcodeSDKDirectory for consistency with the other methods. |
Since the option of going to the "host platform" was discussed already and rejected, I think a new discussion is in order before going back to it. What are the exact circumstances where you did not get a PlatformDarwin object?
Note that I am not opposed (and I never was) having the list of xcode sdk be provided by the "host". However, I don't think it's a good idea to route all of this through the host *platform*, for a couple of reasons:
- it's completely redundant (if I "inline" GetHostPlatform()->GetSDKPath(sdk) I get exactly HostInfo::GetXcodeSDK(sdk))
- it makes it appear like it does more things than it actually does (asking PlatformLinux for an sdk does nothing, and it's not even clear if it should have that api)
- it removes the only usage of "platform" in module code (using platforms in modules is very questionable because it can break caching. In fact, the only reason this usage is not questionable is because the function always returns the exact same value it gets from the host).
You're right. The gist is that the old scheme did not work for debugging iOS processes from a macOS host. The fundamental issue was that GetPlatformForArchitecture chooses the first out of a list of possible platforms, and I the first hit would be a PlatformRemoteGDBServer, which does not inherit from PlatformDarwin. Basically, inside of Module, we don't have enough information (we'd need a Target) to select a meaningful platform.
Note that I am not opposed (and I never was) having the list of xcode sdk be provided by the "host". However, I don't think it's a good idea to route all of this through the host *platform*, for a couple of reasons:
- it's completely redundant (if I "inline" GetHostPlatform()->GetSDKPath(sdk) I get exactly HostInfo::GetXcodeSDK(sdk))
- it makes it appear like it does more things than it actually does (asking PlatformLinux for an sdk does nothing, and it's not even clear if it should have that api)
- it removes the only usage of "platform" in module code (using platforms in modules is very questionable because it can break caching. In fact, the only reason this usage is not questionable is because the function always returns the exact same value it gets from the host).
Good point! The reason why I went with Platform::GetHostPlatform() over HostInfo::GetXcodeSDK(sdk)) was because I hadn't realized that I already put a default implementation of GetXcodeSDK into HostInfoBase, and I wanted to avoid guarding this in an ugly #if APPLE. But I think that that is completely unnecessary.
I'll change it to calling HostInfo directly!
I think this is right, but it looks like you uploaded a diff based on the previous version of the patch instead of the master.
Yeah, having a noop implementation in HostInfoBase is consistent with what we do elsewhere, and with llvm support library for that matter (TBE, the support library usually has an additional bool isFeatureXAvailable() function and the other functions become llvm_unreachable if the feature is really unavailable, but I don't think that's particularly useful for an api with a single entry point).)
This should probably be named GetXcodeSDKDirectory for consistency with the other methods.