llvm dev - Apr 2021 - 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210407/91386fa7/attachment.html>

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

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of
chuanqi.xcq via llvm-dev
Sent: Tuesday, April 6, 2021 10:31 PM
To: llvm-dev at lists.llvm.org
Subject: [llvm-dev] 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210407/009947e2/attachment-0001.html>