[llvm] [RFC] Emit dwarf data for signature-changed or new functions (PR #157349)

[via llvm-commits]

yonghong-song wrote:

> Hi, I've read over this thread but haven't managed to build a full picture of what's being introduced here. I see "RFC" in the PR title - has this change been discussed on discourse? It might be worth doing that if you haven't, to raise awareness, if this is going to affect many debug info consumers.

I have an old discourse thread. I just made some update on it. See
  https://discourse.llvm.org/t/rfc-identify-func-signature-change-in-llvm-compiled-kernel-image/82609/6

Initial format at (https://github.com/llvm/llvm-project/pull/127855) will not change debugger. But it seems not elegant from dwarf perspective. So the new mechanism is to directly encode actual signature in debuginfo/dwarf and use inlinedAt to refer to the original signature.

> 
> As far as I understand it from the thread, this change intends to add an additional DWARF inline scope to functions with changed signatures, where the inline scope has the original signature. Is that right? If so, isn't that going to cause debuggers to spuriously show an extra "inline" frame in the call stack?

Yes. I am not familiar with lldb in this regard. Do we have an example to show how lldb will work in such cases?

> 
>     * Do you intend to have this feature (pass?) enabled by default?

Yes. I do. I suggest to support C language first which probably will have least impact compared to C++ or other languages. If there are non-resolvable issues (I hope not), we may not be able to enable by default. We can have a flag to enable it but when building linux kernel, we can enable this feature.

> 
>     * What assumptions in DWARF consumers is this likely to break?

Good question. I don't have concrete cases for this. I guess the main issue probably with artificial inlining.

https://github.com/llvm/llvm-project/pull/157349