[PATCH] D99179: [RFC] [Coroutines] Enable printing coroutine frame in debugger if program is compiled with -g

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jun 6 16:24:33 PDT 2022


dblaikie added a comment.

In D99179#3559342 <https://reviews.llvm.org/D99179#3559342>, @ChuanqiXu wrote:

> In D99179#3553124 <https://reviews.llvm.org/D99179#3553124>, @probinson wrote:
>
>> @ChuanqiXu the use of DW_ATE_address was a surprise to our debugger; it is a very unusual encoding, and there are no other uses of it within LLVM.  I see there was no Release Note regarding the description of coroutine frames, which might have helped us notice.
>
> Oh, sorry for forgetting about the notes to users. Would try to add one.
>
>> More importantly, I see two places where DW_ATE_address is used in constructing the DWARF, and yet the tests do not look for it.  Please enhance the tests to cover these cases.  I can file an issue if you would like, to keep track of this.
>>
>> But to produce more common/likely-usable DWARF would be to use a pointer_type with no DW_ATE attribute (that's what Clang/LLVM produce for "void*" (DW_TAG_pointer_type with no attributes))
>
> So, it looks like it is not as easy as I imaged to add a test simply, is it? If it is the case, maybe we need an issue actually.

What makes this hard to test? I'd expect putting "assert(false)" in whatever code is currently creating the DW_ATE_address type, testing which test fails, rerunning the test without the assertion and dumping its output should reveal the DW_ATE_address in its output that should be tested (& possibly changed to use a DW_TAG_pointer_type instead)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99179



More information about the llvm-commits mailing list