[PATCH] D127623: [Debug] [Coroutine] Adjust the scope and name for coroutine frame

[Chuanqi Xu via Phabricator via llvm-commits]

ChuanqiXu added a comment.

In D127623#3591432 <https://reviews.llvm.org/D127623#3591432>, @avogelsgesang wrote:

> Can we somehow achieve that for the source code
>
>   std::lazy<int> my_coro_task_function(int x) {
>        while (--x) {
>             co_await do_something();
>        }
>        co_return;
>   }
>
> I can use
>
>   (gdb) # 0x418eb0 is the address of a coroutine frame
>   (gdb )p (my_coro_task_function::__coro_frame_ty)*0x418eb0
>
> in the debugger?
>
> As a user of clang/gdb, I do not want to deal with linkage names at all.
> I would prefer if I could use the non-mangled function name and simply append `::__coro_frame_ty` to it.
> In my mental model, the coroutine frame type is a coroutine-function-local type. As such, writing it as a type nested inside the function scope feels pretty natural to me...

We must not be able to achieve it due to the overloading problem. Long story short, the syntax above is ambiguous if there is another coroutine function with signature ` my_coro_task_function(double x)`.

>From our use experience, your concern doesn't matter really. This is how we debugging coroutines internally:
(1) Write a gdb scripts, let's call it debug-coro.py. And it implemented a gdb command named: print-coro-frame
(2) In gdb, when we want to debug a coroutine, we could run:

  (gdb) source debug-coro.py

(3) The it is simple to print the coroutine frame by:

  (gdb) #0x418eb0 is the address of a coroutine frame
  (gdb) print-coro-frame 0x418eb0 

Then we could get the layout of that coroutine. So the usual user wouldn't see linkage name really. The reason why I didn't post the gdb scripts in D127626 <https://reviews.llvm.org/D127626> is that I feel it might be bad to post gdb script in Clang community. (I feel lldb is competitor with gdb).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127623/new/

https://reviews.llvm.org/D127623