[LLDB] Devirtualize coroutine promise types for `std::coroutine_handle`

[avogelsgesang]

Summary

This commit teaches the std::coroutine_handle pretty-printer to
devirtualize type-erased promise types. This is particularly useful to
resonstruct call stacks, either of asynchronous control flow or of
recursive invocations of std::generator. For the example recently
introduced by https://reviews.llvm.org/D132451, printing the __promise
variable now shows

(std::__coroutine_traits_sfinae<task, void>::promise_type) __promise = {
  continuation = coro frame = 0x555555562430 {
    resume = 0x0000555555556310 (a.out`task detail::chain_fn<1>() at llvm-nested-example.cpp:66)
    destroy = 0x0000555555556700 (a.out`task detail::chain_fn<1>() at llvm-nested-example.cpp:66)
    promise = {
      continuation = coro frame = 0x5555555623e0 {
        resume = 0x0000555555557070 (a.out`task detail::chain_fn<2>() at llvm-nested-example.cpp:66)
        destroy = 0x0000555555557460 (a.out`task detail::chain_fn<2>() at llvm-nested-example.cpp:66)
        promise = {
          ...
        }
      }
      result = 0
    }
  }
  result = 0
}

(shortened to keep the commit message readable) instead of

(std::__coroutine_traits_sfinae<task, void>::promise_type) __promise = {
  continuation = coro frame = 0x555555562430 {
    resume = 0x0000555555556310 (a.out`task detail::chain_fn<1>() at llvm-nested-example.cpp:66)
    destroy = 0x0000555555556700 (a.out`task detail::chain_fn<1>() at llvm-nested-example.cpp:66)
  }
  result = 0
}

Note how the new debug output reveals the complete asynchronous call
stack: our own function resumes chain_fn<1> which in turn will resume
chain_fn<2> and so on. Thereby this change allows users of lldb to
inspect the logical coroutine call stack without using any custom debug
scripts (although the display is still a bit clumsy. It would be nicer
to also integrate this into lldb's backtrace feature, but I don't know
how to do so)

The devirtualization currently works by introspecting the function
pointed to by the destroy pointer. (The resume pointer is not worth
much, given that for the final suspend point resume is set to a
nullptr. We have to use the destroy pointer instead.) We then look
for a __promise variable inside the destroy function. This
__promise variable is synthetically generated by LLVM, and looking at
its type reveals the type-erased promise_type.

This approach only works for clang-generated code, though. While gcc
also adds a _Coro_promise variable to the resume function, it does
not do so for the destroy function. However, we can't use the resume
function, as it will be reset to a nullptr at the final suspension
point. For the time being, I am happy with de-virtualization only working
for clang. A follow-up commit will further improve devirtualization and
also expose the variables spilled to the coroutine frame. As part of
this, I will also revisit gcc support.

[ChuanqiXu]

LGTM basically. Thanks!

[ChuanqiXu]

The only concern is that if it would be not so easy to read if there are too many levels? (Consider the 30levels example in D132451). If it would be better to print ... at certain level? Or this is already handled by lldb?

[avogelsgesang]

The only concern is that if it would be not so easy to read if there are too many levels? (Consider the 30levels example in D132451). If it would be better to print ... at certain level? Or this is already handled by lldb?

Agree, it would be better to limit the printing at some point. However, afaict, limiting the depth to which children are expanded cannot be done from inside the data formatter/synthetic children frontend. I am not sure if lldb already has a separate mechanism in place to limit printing in this case. If it does not, I think it makes sense to add it, but that would be a separate commit

[ChuanqiXu]

In D132624#3748434, @avogelsgesang wrote:

The only concern is that if it would be not so easy to read if there are too many levels? (Consider the 30levels example in D132451). If it would be better to print ... at certain level? Or this is already handled by lldb?

Agree, it would be better to limit the printing at some point. However, afaict, limiting the depth to which children are expanded cannot be done from inside the data formatter/synthetic children frontend. I am not sure if lldb already has a separate mechanism in place to limit printing in this case. If it does not, I think it makes sense to add it, but that would be a separate commit

Yeah, I am not objecting this. I understand it is bad to make perfect the enemy of better.

[labath]

In D132624#3748434, @avogelsgesang wrote:

The only concern is that if it would be not so easy to read if there are too many levels? (Consider the 30levels example in D132451). If it would be better to print ... at certain level? Or this is already handled by lldb?

Agree, it would be better to limit the printing at some point. However, afaict, limiting the depth to which children are expanded cannot be done from inside the data formatter/synthetic children frontend. I am not sure if lldb already has a separate mechanism in place to limit printing in this case. If it does not, I think it makes sense to add it, but that would be a separate commit

The best (I think) mechanism we have is the "pointer depth" limit (defaulting to 1). It works fine on regular objects, but requires some care with synthetic children. The fact that it does not kick in here leads me to believe that the data formatter is creating the synthetic children as non pointer objects (e.g. by automatically dereferencing any nested pointers), even though the structures clearly contain some pointers inside. That is a problem. Not only it creates excessively large outputs, it can even cause lldb to hang (looping endlessly while trying to print "all" children) if the data structures it is trying to print are circular (e.g. due to corruption).

[avogelsgesang]

leads me to believe that the data formatter is creating the synthetic children as non pointer objects (e.g. by automatically dereferencing any nested pointers), even though the structures clearly contain some pointers inside

Yes, that is correct. The formatter (introduced recently in https://reviews.llvm.org/D132415) does dereference the pointer internally. It replaces the

(std::coroutine_handle<>) hdl = {
  __handle_ = 0x55555555b2a0
}

by

(std::coroutine_handle<>) hdl = coro frame = 0x55555555b2a0 {
    resume = 0x0000555555555a10 (a.out`coro_task(int, int) at llvm-example.cpp:36)
    destroy = 0x0000555555556090 (a.out`coro_task(int, int) at llvm-example.cpp:36)
}

by dereferencing the pointer and directly exposing its children.

I could not find a good way to not dereference the pointer internally. Maybe you can help me find a better way?

I tried to just adjust the pointer type of the __handle_ member, but then I got multiple problems:

(1) Unnecessary clutter

(std::coroutine_handle<>) hdl = {
    __handle_ = coro frame = 0x55555555b2a0 {
        resume = 0x0000555555555a10 (a.out`coro_task(int, int) at llvm-example.cpp:36)
        destroy = 0x0000555555556090 (a.out`coro_task(int, int) at llvm-example.cpp:36)
    }
}

The additional __handle_ in it is just visual clutter.

(2) Not expanded by default

By default, if I write p hdl, LLDB did not expand its children and just displayed

(std::coroutine_handle<>) hdl = {
  __handle_ = 0x55555555b2a0
}

without an indication that there was more to see inside the pointer.

Also, when I write p hdl.__handle_, LLDB did not expand the pointer. Because now the hdl.__handle_ access is done with C++ semantics, returning a void* and hence the data formatter for std::exception_handle did not kick in

[labath]

In D132624#3749263, @avogelsgesang wrote:

leads me to believe that the data formatter is creating the synthetic children as non pointer objects (e.g. by automatically dereferencing any nested pointers), even though the structures clearly contain some pointers inside

Yes, that is correct. The formatter (introduced recently in https://reviews.llvm.org/D132415) does dereference the pointer internally. It replaces the

(std::coroutine_handle<>) hdl = {
  __handle_ = 0x55555555b2a0
}

by

(std::coroutine_handle<>) hdl = coro frame = 0x55555555b2a0 {
    resume = 0x0000555555555a10 (a.out`coro_task(int, int) at llvm-example.cpp:36)
    destroy = 0x0000555555556090 (a.out`coro_task(int, int) at llvm-example.cpp:36)
}

The question isn't so much about the dereferencing of actual physical pointers, but more of a any "logical" pointers in the data structures and how they're being presented by the formatters. Most of our formatters dereference some kinds of pointers. For example, a std::set formatter may need to dereference hundreds of pointers to display all of the members. That is OK(*), because those elements are logically "inside" that set. Just like you cannot have a struct S hold itself as a member (only a pointer to S), you also cannot have a std::set contain itself (it would either have to be a pointer, or a set of a different type). And, I think, neither should a coroutine "contain" another coroutine. I don't know much about coroutines, but it seems like your goal is to format them like a linked list, so may the (synthetic) object which represents the "next" coroutine (promise?) in the list should be of a pointer type, forcing the lldb (and user) to do an actual dereference operation before viewing the next element. Maybe that could be achieved by changing the type of __promise.continuation.promise (I'm using the example from your patch description) from std::...::promise_type to std::...::promise_type * ?

(*) However, the formatter should be wary of loops due to corrupted data structures. That's why our std::list formatter has an internal loop detection to prevent it from getting stuck on corrupted lists. AFAIK, our map formatter does not have that, probably because noone ran into that problem yet.

[avogelsgesang]

I don't know much about coroutines, but it seems like your goal is to format them like a linked list

Yes, and no. Coroutines are a compiler-provided type-erasure mechanism which (among other things) erase the type of the contained promise.
One common use case is that the library types (std::generator, the upcoming std::lazy, user-defined types, ...) store a "next"/"continuation" pointer inside that promise.

so maybe the (synthetic) object which represents the "next" coroutine (promise?) in the list should be of a pointer type, forcing the lldb (and user) to do an actual dereference operation before viewing the next element. Maybe that could be achieved by changing the type of __promise.continuation.promise (I'm using the example from your patch description) from std::...::promise_type to std::...::promise_type * ?

Good idea. That should work!

I will prepare a separate review which uses this approach. I would prefer to still first land this patch, then D132735, because I want to reuse helper functions from those two commits for making the proposed change

[avogelsgesang]

I don't know much about coroutines, but it seems like your goal is to format them like a linked list

actually, my preferred goal would be to show them as a logical, user-level thread. Such that you can type

thread backtrace cxxcoro:0x55555555b2a0

to get the backtrace of the logical coroutine thread routed at the coroutine_handle at address 0x55555555b2a0, or maybe even

thread backtrace cxxcoro:hdl

where hdl is evaluated as an expression to identify the coroutine handle from where to dump the backtrace.

Also, it would be neat if those logical threads show up in thread list...

But it seems there is currently no infrastructure yet in LLDB for logical threads provided by LanguageRuntime plugins.

I guess at some point, I will write an RFC about that on discourse. But before that, I will first do some more exploration on how LLDB works and I will first grab the low-hanging fruits (like a data formatter for std::coroutine_handle and patching LLVM to emit the necessary debug info)

[avogelsgesang]

disable tests on gcc

[avogelsgesang]

@labath D132815 addresses your point: With that change, the promise member now is typed as a pointer.

I would prefer to land the patches in the order D132624 (this review), D132735, D132815.

[ChuanqiXu]

In D132624#3754299, @avogelsgesang wrote:

@labath D132815 addresses your point: With that change, the promise member now is typed as a pointer.

I would prefer to land the patches in the order D132624 (this review), D132735, D132815.

You could sort these revisions by 'Edit Related Revisions' automatically.

[avogelsgesang]

@labath @aprantl Thank you for your reviews on https://reviews.llvm.org/D132815 and https://reviews.llvm.org/D132735
I would appreciate if you also have time to review this change here, as it is a pre-requisite for the other two changes :)

[aprantl]

Mechanically this looks good to me.

[avogelsgesang]

Fix ownership of CompilerType between "scratch typesystem" and "module type system"

[avogelsgesang]

@aprantl I still had to adjust the code slightly to copy the type from the ASTContext for '.../a.out' to the scratch ASTContext (without this, my code was triggering an assert).
See https://reviews.llvm.org/D132624?vs=474793&id=475327 for the related changes.
Because I have no prior experience with ClangASTImporter and the usage of multiple different TypeSystemClang instances, I would appreciate if you could take another quick look

[jasonmolenda]

I temporarily reverted this via

commit 2b2f2f66141d52dc0d3082ddd12805d36872a189
Author: Jason Molenda <[e-mail]>
Date:   Fri Nov 25 12:28:28 2022 -0800

    Revert "[LLDB] Recognize `std::noop_coroutine()` in `std::coroutine_handle` pretty printer"
    
    This reverts commit 4346318f5c700f4e85f866610fb8328fc429319b.
    
    This test case is failing on macOS, reverting until it can be
    looked at more closely to unblock the macOS CI bots.
    
      File "/Volumes/work/llvm/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py", line 121, in test_libcpp
        self.do_test(USE_LIBCPP)
      File "/Volumes/work/llvm/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py", line 45, in do_test
        self.expect_expr("noop_hdl",
      File "/Volumes/work/llvm/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2441, in expect_expr
        value_check.check_value(self, eval_result, str(eval_result))
      File "/Volumes/work/llvm/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 306, in check_value
        test_base.assertEqual(self.expect_summary, val.GetSummary(),
    AssertionError: 'noop_coroutine' != 'coro frame = 0x100004058'
    - noop_coroutine+ coro frame = 0x100004058 : (std::coroutine_handle<void>) $1 = coro frame = 0x100004058 {
      resume = 0x0000000100003344 (a.out`___lldb_unnamed_symbol223)
      destroy = 0x0000000100003344 (a.out`___lldb_unnamed_symbol223)
    }
    Checking SBValue: (std::coroutine_handle<void>) $1 = coro frame = 0x100004058 {
      resume = 0x0000000100003344 (a.out`___lldb_unnamed_symbol223)
      destroy = 0x0000000100003344 (a.out`___lldb_unnamed_symbol223)
    }

    Those lldb_unnamed_symbols are synthetic names that ObjectFileMachO
    adds to the symbol table, most often seen with stripped binaries,
    based off of the function start addresses for all the functions -
    if a function has no symbol name, lldb adds one of these names.
    This change was originally landed via https://reviews.llvm.org/D132624

[avogelsgesang]

@jasonmolenda I am a bit confused about your revert.
Did you indeed revert this change here? Afaict, you reverted https://reviews.llvm.org/D132735 and https://reviews.llvm.org/D132815, but left this commit in place. I did not actually read through your code changes, though, I only looked at the commit messages so far. Is my understanding of which commits you actually reverted correct?

[jasonmolenda]

In D132624#3951525, @avogelsgesang wrote:

@jasonmolenda I am a bit confused about your revert.
Did you indeed revert this change here? Afaict, you reverted https://reviews.llvm.org/D132735 and https://reviews.llvm.org/D132815, but left this commit in place. I did not actually read through your code changes, though, I only looked at the commit messages so far. Is my understanding of which commits you actually reverted correct?

Ah sigh. :( I reverted both https://reviews.llvm.org/D132624 and https://reviews.llvm.org/D132735 -- failed to comment here in https://reviews.llvm.org/D132624 that I reverted the change, and put the comment about https://reviews.llvm.org/D132735 in the wrong phabracator. I don't know how I got the two mixed up in so many ways ;) but they are both backed out right now and we have a green status on the macOS Incremental CI bot https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/

The mixup I can see, but I don't know how I failed to comment in this one about it being reverted. I must not have hit a Submit button, apologies.

lldb/source/Plugins/Language/CPlusPlus/Coroutines.cpp

 //===-- Coroutines.cpp ----------------------------------------------------===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //===----------------------------------------------------------------------===//
 
 #include "Coroutines.h"
 
 #include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
+#include "lldb/Symbol/Function.h"
+#include "lldb/Symbol/VariableList.h"
 
 using namespace lldb;
 using namespace lldb_private;
 using namespace lldb_private::formatters;
 
 static ValueObjectSP GetCoroFramePtrFromHandle(ValueObject &valobj) {
   ValueObjectSP valobj_sp(valobj.GetNonSyntheticValue());
   if (!valobj_sp)
     return nullptr;
 
   // We expect a single pointer in the `coroutine_handle` class.
   // We don't care about its name.
   if (valobj_sp->GetNumChildren() != 1)
     return nullptr;
   ValueObjectSP ptr_sp(valobj_sp->GetChildAtIndex(0, true));
   if (!ptr_sp)
     return nullptr;
   if (!ptr_sp->GetCompilerType().IsPointerType())
     return nullptr;
 
   return ptr_sp;
 }
 
+static Function *ExtractDestroyFunction(ValueObjectSP &frame_ptr_sp) {
+  lldb::TargetSP target_sp = frame_ptr_sp->GetTargetSP();
+  lldb::ProcessSP process_sp = frame_ptr_sp->GetProcessSP();
+  auto ptr_size = process_sp->GetAddressByteSize();
+
+  AddressType addr_type;
+  lldb::addr_t frame_ptr_addr = frame_ptr_sp->GetPointerValue(&addr_type);
+  if (!frame_ptr_addr || frame_ptr_addr == LLDB_INVALID_ADDRESS)
+    return nullptr;
+  lldbassert(addr_type == AddressType::eAddressTypeLoad);
+
+  Status error;
+  // The destroy pointer is the 2nd pointer inside the compiler-generated
+  // `pair<resumePtr,destroyPtr>`.
+  auto destroy_func_ptr_addr = frame_ptr_addr + ptr_size;
+  lldb::addr_t destroy_func_addr =
+      process_sp->ReadPointerFromMemory(destroy_func_ptr_addr, error);
+  if (error.Fail())
+    return nullptr;
+
+  Address destroy_func_address;
+  if (!target_sp->ResolveLoadAddress(destroy_func_addr, destroy_func_address))
+    return nullptr;
+
+  Function *destroy_func =
+      destroy_func_address.CalculateSymbolContextFunction();
+  if (!destroy_func)
+    return nullptr;
+
+  return destroy_func;
+}
+
+static CompilerType InferPromiseType(Function &destroy_func) {
+  SymbolContext sc;
+  Block &block = destroy_func.GetBlock(true);
+  auto variable_list = block.GetBlockVariableList(true);
+
+  // clang generates an artificial `__promise` variable inside the
+  // `destroy` function. Look for it.
+  auto promise_var = variable_list->FindVariable(ConstString("__promise"));
+  if (!promise_var)
+    return {};
+  if (!promise_var->IsArtificial())
+    return {};
+
+  Type *promise_type = promise_var->GetType();
+  if (!promise_type)
+    return {};
+  return promise_type->GetForwardCompilerType();
+}
+
 static CompilerType GetCoroutineFrameType(TypeSystemClang &ast_ctx,
                                           CompilerType promise_type) {
   CompilerType void_type = ast_ctx.GetBasicType(lldb::eBasicTypeVoid);
   CompilerType coro_func_type = ast_ctx.CreateFunctionType(
       /*result_type=*/void_type, /*args=*/&void_type, /*num_args=*/1,
       /*is_variadic=*/false, /*qualifiers=*/0);
   CompilerType coro_abi_type;
   if (promise_type.IsVoidType()) {

 }
 
 bool lldb_private::formatters::StdlibCoroutineHandleSummaryProvider(
     ValueObject &valobj, Stream &stream, const TypeSummaryOptions &options) {
   ValueObjectSP ptr_sp(GetCoroFramePtrFromHandle(valobj));
   if (!ptr_sp)
     return false;
 
+  if (!ptr_sp->GetValueAsUnsigned(0)) {
+    stream << "nullptr";
+  } else {
     stream.Printf("coro frame = 0x%" PRIx64, ptr_sp->GetValueAsUnsigned(0));
+  }
   return true;
 }
 
 lldb_private::formatters::StdlibCoroutineHandleSyntheticFrontEnd::
     StdlibCoroutineHandleSyntheticFrontEnd(lldb::ValueObjectSP valobj_sp)
     : SyntheticChildrenFrontEnd(*valobj_sp) {
   if (valobj_sp)
     Update();
bool lldb_private::formatters::StdlibCoroutineHandleSyntheticFrontEnd::
   ValueObjectSP valobj_sp = m_backend.GetSP();
   if (!valobj_sp)
     return false;
 
   ValueObjectSP ptr_sp(GetCoroFramePtrFromHandle(m_backend));
   if (!ptr_sp)
     return false;
 
-  TypeSystemClang *ast_ctx = llvm::dyn_cast_or_null<TypeSystemClang>(
-      valobj_sp->GetCompilerType().GetTypeSystem());
-  if (!ast_ctx)
-    return false;
-
+  // Get the `promise_type` from the template argument
   CompilerType promise_type(
       valobj_sp->GetCompilerType().GetTypeTemplateArgument(0));
   if (!promise_type)
     return false;
+
+  // Try to infer the promise_type if it was type-erased
+  if (promise_type.IsVoidType()) {
+    if (Function *destroy_func = ExtractDestroyFunction(ptr_sp)) {
+      if (CompilerType inferred_type = InferPromiseType(*destroy_func)) {
+        promise_type = inferred_type;
+      }
+    }
+  }
+
+  // Build the coroutine frame type
+  TypeSystemClang *ast_ctx = llvm::dyn_cast_or_null<TypeSystemClang>(
+      ptr_sp->GetCompilerType().GetTypeSystem());
+  if (!ast_ctx)
+    return {};
   CompilerType coro_frame_type = GetCoroutineFrameType(*ast_ctx, promise_type);
 
   m_frame_ptr_sp = ptr_sp->Cast(coro_frame_type.GetPointerType());
 
   return false;
 }
 
 bool lldb_private::formatters::StdlibCoroutineHandleSyntheticFrontEnd::

lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/TestCoroutineHandle.py

 
 USE_LIBSTDCPP = "USE_LIBSTDCPP"
 USE_LIBCPP = "USE_LIBCPP"
 
 class TestCoroutineHandle(TestBase):
     def do_test(self, stdlib_type):
         """Test std::coroutine_handle is displayed correctly."""
         self.build(dictionary={stdlib_type: "1"})
+        is_clang = self.expectedCompiler(["clang"])
 
         test_generator_func_ptr_re = re.compile(
                 r"^\(a.out`my_generator_func\(\) at main.cpp:[0-9]*\)$")
 
         # Run until the initial suspension point
         lldbutil.run_to_source_breakpoint(self, '// Break at initial_suspend',
                 lldb.SBFileSpec("main.cpp", False))
 
         if self.frame().FindVariable("is_supported").GetValueAsUnsigned(1) == 0:
             self.skipTest("c++ library not supported")
 
         # Check that we show the correct function pointers and the `promise`. 
         self.expect_expr("gen.hdl",
             result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
             result_children=[
                 ValueCheck(name="resume", summary = test_generator_func_ptr_re),
                 ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
                 ValueCheck(name="promise", children=[
                     ValueCheck(name="current_value", value = "-1"),
                 ])
             ])
-        # For type-erased `coroutine_handle<>` we are missing the `promise`
-        # but still show `resume` and `destroy`.
+        if is_clang:
+            # For a type-erased `coroutine_handle<>`, we can still devirtualize
+            # the promise call and display the correctly typed promise.
             self.expect_expr("type_erased_hdl",
                 result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
                 result_children=[
                     ValueCheck(name="resume", summary = test_generator_func_ptr_re),
                     ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+                    ValueCheck(name="promise", children=[
+                        ValueCheck(name="current_value", value = "-1"),
+                    ])
+                ])
+            # For an incorrectly typed `coroutine_handle`, we use the user-supplied
+            # incorrect type instead of inferring the correct type. Strictly speaking,
+            # incorrectly typed coroutine handles are undefined behavior. However,
+            # it provides probably a better debugging experience if we display the
+            # promise as seen by the program instead of fixing this bug based on
+            # the available debug info.
+            self.expect_expr("incorrectly_typed_hdl",
+                result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+                result_children=[
+                    ValueCheck(name="resume", summary = test_generator_func_ptr_re),
+                    ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+                    ValueCheck(name="promise", value="-1")
                 ])
 
         # Run until after the `co_yield`
         process = self.process()
         lldbutil.continue_to_source_breakpoint(self, process,
                 '// Break after co_yield', lldb.SBFileSpec("main.cpp", False))
         # We correctly show the updated value inside `prommise.current_value`.
         self.expect_expr("gen.hdl",
             result_children=[
def do_test(self, stdlib_type):
         self.expect_expr("gen.hdl",
             result_children=[
                 ValueCheck(name="resume", value = re.compile("^0x0+$")),
                 ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
                 ValueCheck(name="promise", children=[
                     ValueCheck(name="current_value", value = "42"),
                 ])
             ])
+        if is_clang:
+            # Devirtualization still works, also at the final suspension point, despite
+            # the `resume` pointer being reset to a nullptr
+            self.expect_expr("type_erased_hdl",
+                result_summary=re.compile("^coro frame = 0x[0-9a-f]*$"),
+                result_children=[
+                    ValueCheck(name="resume", value = "0x0000000000000000"),
+                    ValueCheck(name="destroy", summary = test_generator_func_ptr_re),
+                    ValueCheck(name="promise", children=[
+                        ValueCheck(name="current_value", value = "42"),
+                    ])
+                ])
 
     @add_test_categories(["libstdcxx"])
     def test_libstdcpp(self):
         self.do_test(USE_LIBSTDCPP)
 
     @add_test_categories(["libc++"])
     def test_libcpp(self):
         self.do_test(USE_LIBCPP)

lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic/coroutine_handle/main.cpp

 // This is an empty function which we call just so the debugger has
 // a place to reliably set a breakpoint on.
 void empty_function_so_we_can_set_a_breakpoint() {}
 
 int main() {
   bool is_supported = is_implementation_supported();
   int_generator gen = my_generator_func();
   std::coroutine_handle<> type_erased_hdl = gen.hdl;
+  std::coroutine_handle<int> incorrectly_typed_hdl =
+      std::coroutine_handle<int>::from_address(gen.hdl.address());
   gen.hdl.resume();                            // Break at initial_suspend
   gen.hdl.resume();                            // Break after co_yield
   empty_function_so_we_can_set_a_breakpoint(); // Break at final_suspend
 }