HomePhabricator

[Coroutines] Enable printing coroutine frame when dbg info is available

Authored by ChuanqiXu on May 12 2021, 9:35 PM.

Description

[Coroutines] Enable printing coroutine frame when dbg info is available

Summary: This patch tries to build debug info for coroutine frame in the
middle end. Although the coroutine frame is constructed and maintained by
the compiler and the programmer shouldn't care about the coroutine frame
by the design of C++20 coroutine,
a lot of programmers told me that they want to see the layout of the
coroutine frame strongly. Although C++ is designed as an abstract layer
so that the programmers shouldn't care about the actual memory in bits,
many experienced C++ programmers are familiar with assembler and
debugger to see the memory layout in fact, After I was been told they
want to see the coroutine frame about 3 times, I think it is an actual
and desired demand.

However, the debug information is constructed in the front end and
coroutine frame is constructed in the middle end. This is a natural and
clear gap. So I could only try to construct the debug information in the
middle end after coroutine frame constructed. It is unusual, but we are
in consensus that the approch is the best one.

One hard part is we need construct the name for variables since there
isn't a map from llvm variables to DIVar. Then here is the strategy this
patch uses:

  • The name __resume_fn , __destroy_fn and __coro_index are constructed by the patch.
  • Then the name __promise comes from the dbg.variable of corresponding dbg.declare of PromiseAlloca, which shows highest priority to

construct the debug information for the member of coroutine frame.

  • Then if the member is struct, we would try to get the name of the llvm struct directly. Then replace ':' and '.' with '_' to make it

printable for debugger.

  • If the member is a basic type like integer or double, we would try to emit the corresponding name.
  • Then if the member is a Pointer Type, we would add Ptr after corresponding pointee type.
  • Otherwise, we would name it with 'UnknownType'.

Reviewered by: lxfind, aprantl, rjmcall, dblaikie

Differential Revision: https://reviews.llvm.org/D99179