Any suggestions for the name for the type of coroutine frame?

[ChuanqiXu9]

The post is not an issue. It asks for the suggestion for the name for the type of coroutine frame.

The coroutine frame in clang is constructed in the middle end. And I tried to generate the debug information at the middle end to assist debugging as much as possible. Now it becomes a problem what the name for the type of coroutine frame. I suggested to use function_linkage_name + __coro_frame_ty suffix since the type of coroutine frame is fixed for every coroutine function.

But @dwblaikie points out that name is not good for demangling. Although we tried function_linkage_name + .coro_frame_ty, the name would be treated as a function name. Then we are going to see if there any method to separate function_linkage_name and __coro_frame_ty to make people could pass the linkage name to the demangler to get demangled name.

I feel like function_linkage_name + __coro_frame_ty might be good. People could get the rid of suffix easily to me. But @dwblaikie prefer something like coro_frame_ty_Zxxx. He feel like it is hard to figure out what is the end of the suffix.

So we come to here to ask for an advice. The full discussion context could be found at: https://reviews.llvm.org/D127623

Thanks, Chuanqi

[rjmccall]

Those approaches both feel like they're blending encoding schemas, which I'm never a big fan of; I always prefer to find a way to fit names into an existing schema. One option for doing that if you're starting with a C++ mangled name for the function (which should be predominant for C++ coroutines, although I suppose it's legal to declare one extern "C"?) would be to produce a C++ mangled name for the frame type as if it were some sort of local declaration.

The standard mangling for a local entity in C++ is:

<local-name> ::= Z <function encoding> E <entity name> [<discriminator>]

So basically you would recognize that the function name starts with _Z, replace that prefix with _ZZ, tack an E on the end, and then add a suffix that uniquely identifies this type as the coroutine frame. That suffix could be something in the reserved namespace, e.g. 12__coro_frame, or you could ask us to give you a special name that's unambiguous with anything that could possibly be declared by the user.

You would still have to come up with your own schema for function names that don't start with _Z. That will affect C linkage names as well as coroutines lowered from other languages. In some ways, the latter seems actively desirable — I'm certain Swift would appreciate being able to use its own mangling scheme for frame names. On the other hand, if clients like LLDB want to be able to recognize coroutine frames in a language-agnostic way, that might not be a good idea, and you should just find a simple schema that's agnostic about the symbol mangling schema in use.

[ChuanqiXu9]

Thanks for the writing up! I learned a lot.

Finally we decide to use linkage_name.coro_frame_ty due to the C linkage couldn't use C++ ABI and we want to keep things uniform.

You would still have to come up with your own schema for function names that don't start with _Z. That will affect C linkage names as well as coroutines lowered from other languages.

From the current implementation, it wouldn't affect other languages like Swift or MLIR. So it might be fine temporarily.