This is an archive of the discontinued LLVM Phabricator instance.

Move the Xcode SDK path caching to HostInfo
ClosedPublic

Authored by aprantl on May 4 2020, 1:53 PM.

Details

Summary

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.

Diff Detail

Event Timeline

aprantl created this revision.May 4 2020, 1:53 PM
JDevlieghere accepted this revision.May 4 2020, 2:00 PM

LGTM modulo the inline comment.

lldb/include/lldb/Host/HostInfoBase.h
96

This should probably be named GetXcodeSDKDirectory for consistency with the other methods.

This revision is now accepted and ready to land.May 4 2020, 2:00 PM
labath added a subscriber: labath.May 5 2020, 2:36 AM

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).
aprantl marked an inline comment as done.May 5 2020, 9:51 AM

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?

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!

aprantl updated this revision to Diff 262184.May 5 2020, 11:22 AM

Removed the Platform detour.

labath added a comment.May 6 2020, 1:21 AM

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.

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.

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 revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMay 6 2020, 2:10 PM