Should we construct debug information in LLVM?

Hi,

Recently I am working on constructing debug information in LLVM for C++ Coroutine Frame: https://reviews.llvm.org/D99179.
The reason why we can’t construct thr debug information for C++ Coroutine Frame in the frontend is the framework of LLVM
coroutine decides to construct the frame in the middle end. So we can’t know the layout of the coroutine frame until the coro-split
pass.

Then a lot of my collegues told me many times that it is very important to them to see the frame in the debugger in production
environment. Although many things in the frame are temporaries produced by compiler, my collegues are still satisfied to see the
frame.

But I am also agree with that it is a little bit odd to contruct the debug information in the middle end. I get this from the API
design. And about half of codes in D99179 are trying to construct the debug information from corresponding LLVM type, which
is unrelated to coroutine module.

As the reviewer’s suggestion, I want to ask the opinion from the debug info folks:

  • Is it ok to construct debug information in LLVM Passes?
  • If no, is there any method to help us to solve these problems?

Thanks,
Chuanqi

Note to other responders: It is extremely helpful to read the comments in the linked review. Most of my immediate reactions to the questions are already brought up there.

Normally we would not want the middle end to construct new debug info, but as noted in the review, it seems like the most reasonable approach for this specific case. Anything you do construct in the middle end should be marked as “artificial” (there should be a flag for that).

I haven’t looked at the patch in any detail, but if the types for your artificial variables are copied from existing source variables, you can just reuse the type info from the debug info for those source variables. If the artificial variable types are independent of source variables, then you would create new types and mark them as artificial. If you do create new types, you probably want to cache them if these frames can occur in more than one place; that is to avoid bloating the debug info.

If you know the source language is C/C++, then it might be helpful to use ‘__’ prefixes to avoid name collisions with real types and variables. It seems that Swift doesn’t want the extra debug info, and I don’t know what the Fortran conventions are.

Hope this helps,

–paulr

yeah, looks like upstream review is continuing in this direction - I'm
OK with it.

Note to other responders: It is extremely helpful to read the comments in the linked review. Most of my immediate reactions to the questions are already brought up there.

Normally we would not want the middle end to construct new debug info, but as noted in the review, it seems like the most reasonable approach for this specific case. Anything you do construct in the middle end should be marked as “artificial” (there should be a flag for that).

I haven’t looked at the patch in any detail, but if the types for your artificial variables are copied from existing source variables, you can just reuse the type info from the debug info for those source variables. If the artificial variable types are independent of source variables, then you would create new types and mark them as artificial. If you do create new types, you probably want to cache them if these frames can occur in more than one place; that is to avoid bloating the debug info.

^ Chuanqi - have you considered/tested/supported this? (eg: if two
distinct coroutines (with and without similar/matching frame layouts)
do any duplicate debug metadata records end up created? It'd be good
to make sure that doesn't happen)