[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#3583060 <https://reviews.llvm.org/D127623#3583060>, @dblaikie wrote:

> In D127623#3580865 <https://reviews.llvm.org/D127623#3580865>, @ChuanqiXu wrote:
>
>> In D127623#3580751 <https://reviews.llvm.org/D127623#3580751>, @ChuanqiXu wrote:
>>
>>> In D127623#3579786 <https://reviews.llvm.org/D127623#3579786>, @dblaikie wrote:
>>>
>>>> I believe there's particular syntax that's supported by demanglers for suffixes - (specifically, at least for itanium, using "." to separate the suffix from the symbol name will support demanglers doing good things with the name when demangling) - could you check whether that applies here, if we have any tools/utility functions that handle this sort of suffix additions in a portable/tool-compatible way, etc, and do that?
>>>
>>> For c++filt, the result for `_ZL9coro_taski.coro_frame_ty` is 'coro_task(int) [clone .coro_frame_ty]' and for llvm-cxxfilt, the corresponding result is `coro_task(int) (.coro_frame_ty)`. I feel things are better now.
>>
>> Oh, this one might be problematic. Now the debugger complains for the following command:
>>
>>     (gdb) # 0x418eb0 is the address of a coroutine frame
>>     (gdb )p (_ZL9coro_taski.coro_frame_ty)*0x418eb0
>>   Attempt to extract a component of a value that is not a structure.
>>
>> It looks like the debugger treat `_ZL9coro_taski.coro_frame_ty` as a function name to me.
>
> oh, `_ZL9coro_taski` is a function name - but because you were appending "__coro_frame_ty" to the end of it you were breaking the mangling and causing the consumer to no longer recognize it as a function?
>
> hmm, I guess because the mangling includes parameter types it interprets it as a function. Fair enough I suppose.
>
> Yeah, maybe there's some other separator that could be used that'd at least make it easier for a human to know where the mangled name ends and the suffix begins that doesn't confuse a debugger - that way the human could always pass the mangled portion to a demangler (c++filt, etc) to get the original function name?

Do you mean something like this: `_ZN14_ZL9coro_taski13coro_frame_tyE`? The detangled result would be `_ZL9coro_taski::coro_frame_ty`. So the human could pass the mangled portion `_ZL9coro_taski ` to the demangler.

But this one is not satisfying to me. My original idea is that users could get the coroutine type name easily by concatenating the linkage name and the suffix `__coro_frame_ty`. But in the above fashion, things goes complicated. They need to count the size of the linkage name, concatenating "13coro_frame_ty" and put the result in `_ZN` and `E`. I feel like it is not user friendly enough.

For the demangle part, I think the user could erase the suffix "__coro_frame_ty" easily. For tooling side, I am willing to see if I can implement it in llvm/Demangler.

> (or maybe using a prefix instead of a suffix, and the "_Z" would stand out enough to make it easy for a human to copy/paste "_Z" to the end of the name and demangle that?

I feel like this is not friendly enough. It requires the user to know "_Z" stands for the start of a mangled name. But I think most of the programmer lack the knowledge.


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

https://reviews.llvm.org/D127623