Skip to content

Conversation

@charles-zablit
Copy link
Contributor

@charles-zablit charles-zablit commented Jun 27, 2025

This patch is part of an effort to remove the ResolveSDKPathFromDebugInfo method, and more specifically the variant which takes a Module as argument.

See the following PR for a follow up on what to do:

@llvmbot
Copy link
Member

llvmbot commented Jun 27, 2025

@llvm/pr-subscribers-lldb

Author: Charles Zablit (charles-zablit)

Changes

This patch is part of an effort to remove the ResolveSDKPathFromDebugInfo method, and more specifically the variant which takes a Module as argument.

This PR should be merged after #144913.


Full diff: https://github.com/llvm/llvm-project/pull/146062.diff

1 Files Affected:

  • (modified) lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp (+26-6)
diff --git a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
index 262a7dc731713..ae46ac63e756a 100644
--- a/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
+++ b/lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
@@ -1130,13 +1130,33 @@ void PlatformDarwin::AddClangModuleCompilationOptionsForSDKType(
 
   if (target) {
     if (ModuleSP exe_module_sp = target->GetExecutableModule()) {
-      auto path_or_err = ResolveSDKPathFromDebugInfo(*exe_module_sp);
-      if (path_or_err) {
-        sysroot_spec = FileSpec(*path_or_err);
+      SymbolFile *sym_file = exe_module_sp->GetSymbolFile();
+      if (!sym_file)
+        return;
+
+      XcodeSDK merged_sdk;
+      for (unsigned i = 0; i < sym_file->GetNumCompileUnits(); ++i) {
+        if (auto cu_sp = sym_file->GetCompileUnitAtIndex(i)) {
+          auto cu_sdk = sym_file->ParseXcodeSDK(*cu_sp);
+          merged_sdk.Merge(cu_sdk);
+        }
+      }
+
+      // TODO: The result of this loop is almost equivalent to deriving the SDK
+      // from the target triple, which would be a lot cheaper.
+
+      if (FileSystem::Instance().Exists(merged_sdk.GetSysroot())) {
+        sysroot_spec = merged_sdk.GetSysroot();
       } else {
-        LLDB_LOG_ERROR(GetLog(LLDBLog::Types | LLDBLog::Host),
-                       path_or_err.takeError(),
-                       "Failed to resolve SDK path: {0}");
+        auto path_or_err =
+            HostInfo::GetSDKRoot(HostInfo::SDKOptions{merged_sdk});
+        if (path_or_err) {
+          sysroot_spec = FileSpec(*path_or_err);
+        } else {
+          LLDB_LOG_ERROR(GetLog(LLDBLog::Types | LLDBLog::Host),
+                         path_or_err.takeError(),
+                         "Failed to resolve SDK path: {0}");
+        }
       }
     }
   }

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we put all of this into a static helper in this file? Maybe call it ResolveSDKPathFromDebugInfo too

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extracted and refactored the logic a bit to ResolveSDKPathFromDebugInfo 👍

Comment on lines 1131 to 1132
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't think we want to return here? We used to just to log the error. How about we return llvm::Expected from ResolveSDKPathFromDebugInfo and don't pass the sysroot_spec as an output parameter?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fixed the logic and switched to an llvm::Expected return type. The underlying error are logged after the function is called.

Copy link
Member

@Michael137 Michael137 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just some final stylistic comments

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nit: I would invert this condition and return error if !path_or_err.

Then return FileSpec(*path_or_err) as the last return from this function. So we're consistent with all the other early returns in this function

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't need this to be in the header. We can just make it local to the .cpp file

Copy link
Collaborator

@adrian-prantl adrian-prantl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with Michael's comments addressed.

@charles-zablit charles-zablit force-pushed the charles-zablit/lldb/inline-method branch from dd30697 to a174359 Compare June 30, 2025 17:18
@charles-zablit charles-zablit merged commit 0c124be into llvm:main Jul 1, 2025
7 checks passed
kastiglione added a commit that referenced this pull request Aug 21, 2025
…54607)

While debugging, I saw a log line of:

> Failed to resolve SDK path: Error while searching for SDK (XcodeSDK ''): Unrecognized SDK type:

Looking into how this might happen, it seems `ResolveSDKPathFromDebugInfo` appears to
(implicitly) assume there's at least one compile unit. This change adds a precondition
to return a meaningful error when there are no compile units.

Original: #146062
llvm-sync bot pushed a commit to arm/arm-toolchain that referenced this pull request Aug 21, 2025
…o (NFC) (#154607)

While debugging, I saw a log line of:

> Failed to resolve SDK path: Error while searching for SDK (XcodeSDK ''): Unrecognized SDK type:

Looking into how this might happen, it seems `ResolveSDKPathFromDebugInfo` appears to
(implicitly) assume there's at least one compile unit. This change adds a precondition
to return a meaningful error when there are no compile units.

Original: llvm/llvm-project#146062
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants