[lldb] Adopt new pointer and mangled typename based stringForPrintObject #11916

kastiglione · 2025-12-03T00:00:43Z

Adopt stringForPrintObject(_:mangledTypeName:), an overload added in swiftlang/swift#84742.

This new overload allows lldb to call stringForPrintObject using only a pointer referencing the value, and the mangled typename corresponding to the value. The resulting expression does not reference the concrete type.

By not referencing a value's type, po can be performed on variables (and their nested stored properties) without loading the modules corresponding to the value's type. This will improve performance and reliability of po.

rdar://158968103

Adopt `stringForPrintObject(_:mangledTypeName:)`, an overload added in swiftlang/swift#84742. This new overload allows lldb to call `stringForPrintObject` using only a pointer referencing the value, and the mangled typename corresponding to the value. The resulting expression does not reference the concrete type. By not referencing a value's type, `po` can be performed on variables (and their nested stored properties) without loading the modules corresponding to the value's type. This will improve performance and reliability of `po`.

kastiglione · 2025-12-03T00:00:45Z

@swift-ci test

kastiglione · 2025-12-03T00:02:23Z

Draft mode: follow up will include experimental setting, and tests.

kastiglione · 2025-12-03T00:06:05Z

@swift-ci test

kastiglione · 2025-12-03T06:38:12Z

@swift-ci test macOS

kastiglione · 2025-12-03T16:42:17Z

Existing tests all pass with new po.

kastiglione · 2025-12-03T23:38:58Z

@swift-ci test

lldb/source/Target/TargetProperties.td

lldb/source/Plugins/ExpressionParser/Swift/SwiftExpressionSourceCode.cpp

adrian-prantl · 2025-12-03T23:51:13Z

lldb/source/Plugins/LanguageRuntime/Swift/SwiftLanguageRuntime.cpp

  return false;
 }

+static bool printObjectViaPointer(Stream &strm, ValueObject &object,


Should this function return llvm::Error and return createStringError for the various failure modes for easier debugging?

I'm not able to picture how this improves debugging? Can you walk me through it?

adrian-prantl · 2025-12-03T23:51:41Z

lldb/source/Plugins/LanguageRuntime/Swift/SwiftLanguageRuntime.cpp

+  auto result_or_err = runObjectDescription(object, expr_string, process, true);
+  if (!result_or_err) {
+    LLDB_LOG_ERROR(log, result_or_err.takeError(),
+                   "stringForPrintObject(_:mangledTypeName:) failed: {0}");


then this could just be return result_or_err.takeError()

Wouldn't returning lose the context of stringForPrintObject(_:mangledTypeName:) being the source of the error?

You could do joinError(createStringError(..), esult_or_err.takeError()).

adrian-prantl · 2025-12-03T23:54:36Z

...est/API/lang/swift/po/pointer_and_mangled_typename/TestSwiftPrintObjectPointerAndTypeName.py

+        )
+        self.expect("po value", substrs=["2025"])
+        self._filecheck("INT")
+        # CHECK-INT: stringForPrintObject(UnsafeRawPointer(bitPattern: {{[0-9]+}}), mangledTypeName: "SiD")


Neat test, reusing filecheck this way!

lldb/source/Plugins/LanguageRuntime/Swift/SwiftLanguageRuntime.cpp

augusto2112 · 2025-12-04T14:11:51Z

lldb/source/Plugins/LanguageRuntime/Swift/SwiftLanguageRuntime.cpp

+
+  StringRef mangled_type_name = object.GetMangledTypeName();
+  // Swift's APIs that accept mangled names require the "$s" prefix removed.
+  mangled_type_name.consume_front("$s");


"$e" is also valid mangling for embedded Swift.

Also, when I see mangled names without the front "$s" omitted, I also see it with the last "D" omitted too (I think that's a "TypeMangling" node). I guess this isn't necessary here?

The removes $e prefixes now.

I guess this isn't necessary here?

Not that I've seen. Tests work without having to make any adjustments to suffix.

jimingham · 2025-12-04T22:41:44Z

lldb/source/Plugins/ExpressionParser/Swift/SwiftExpressionSourceCode.cpp

+          bool is_simulator = platform->GetPluginName().ends_with("-simulator");
+          if (is_simulator) {
+            // The simulators look like the host OS to Process, but Platform
+            // can the version out of an environment variable.


"can the" -> "can get the"

jimingham · 2025-12-04T22:42:37Z

lldb/source/Plugins/ExpressionParser/Swift/SwiftExpressionSourceCode.cpp

-          llvm::VersionTuple version = process_sp->GetHostOSVersion();
-          os_vers << version.getAsString();
+          auto platform = target->GetPlatform();
+          bool is_simulator = platform->GetPluginName().ends_with("-simulator");


Do we really not have a nicer way to tell if a Platform is a simulator?

There's Triple::isSimulatorEnvironment but it's unclear if that applies here, based on the comment:

// The simulators look like the host OS to Process, but Platform // can get the version out of an environment variable.

jimingham · 2025-12-04T22:45:11Z

lldb/include/lldb/Target/Target.h


  bool GetPreparePlaygroundStubFunctions() const { return m_prepare_playground_stub_functions; }

+  void SetDisableAvailability() { m_disable_availability = true; }


This is an odd set API. It only allows you to set it to true, which the name doesn't really imply?

We usually do:

SetWhatever(bool new_value)

which the name doesn't really imply?

It doesn't? I'm failing to see how it would be interpreted otherwise…

There's no reason for code to call SetDisableAvailability(False), as that is the default. Since there's no reason for it to be called like that, I made the function take no arguments, so that it can be called only one way. This may be different than other bool setters, but I feel it's better prevent it from being mis-called than make it match other setters.

lldb/source/Plugins/LanguageRuntime/Swift/SwiftLanguageRuntime.cpp

jimingham · 2025-12-04T22:50:01Z

lldb/source/Plugins/LanguageRuntime/Swift/SwiftLanguageRuntime.cpp

+  addr_t addr = LLDB_INVALID_ADDRESS;
+  if (flags.Test(eTypeInstanceIsPointer)) {
+    // Objects are pointers.
+    addr = object.GetValueAsUnsigned(LLDB_INVALID_ADDRESS);


This should use GetValueAsAddress.

GetValueAsAddress is on SBValue, I don't see an equivalent on ValueObject.

kastiglione · 2025-12-09T18:43:46Z

@swift-ci test

adrian-prantl

LGTM with outstanding feedback addressed.

kastiglione requested a review from a team as a code owner December 3, 2025 00:00

kastiglione marked this pull request as draft December 3, 2025 00:00

Fix missing rename

9cd7c44

kastiglione requested a review from adrian-prantl December 3, 2025 00:21

kastiglione added 2 commits December 3, 2025 10:50

Add setting gating the new po, initially disabled by default

3c969d6

Add tests for new po

caade22

kastiglione marked this pull request as ready for review December 3, 2025 23:38

kastiglione requested review from augusto2112, felipepiovezan and jimingham December 3, 2025 23:45

adrian-prantl reviewed Dec 3, 2025

View reviewed changes

augusto2112 approved these changes Dec 4, 2025

View reviewed changes

jimingham reviewed Dec 4, 2025

View reviewed changes

lldb/source/Plugins/LanguageRuntime/Swift/SwiftLanguageRuntime.cpp Outdated Show resolved Hide resolved

jimingham reviewed Dec 4, 2025

View reviewed changes

kastiglione added 3 commits December 9, 2025 10:27

Update names

defe915

Support embedded swift prefix

ff4b066

Update comment about OS version 9999

714c3bb

adrian-prantl approved these changes Dec 9, 2025

View reviewed changes


		bool GetPreparePlaygroundStubFunctions() const { return m_prepare_playground_stub_functions; }

		void SetDisableAvailability() { m_disable_availability = true; }

[lldb] Adopt new pointer and mangled typename based stringForPrintObject #11916

Are you sure you want to change the base?

[lldb] Adopt new pointer and mangled typename based stringForPrintObject #11916

Conversation

kastiglione commented Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kastiglione commented Dec 3, 2025

Uh oh!

kastiglione commented Dec 3, 2025

Uh oh!

kastiglione commented Dec 3, 2025

Uh oh!

kastiglione commented Dec 3, 2025

Uh oh!

kastiglione commented Dec 3, 2025

Uh oh!

kastiglione commented Dec 3, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kastiglione commented Dec 9, 2025

Uh oh!

adrian-prantl left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

kastiglione commented Dec 3, 2025 •

edited

Loading