[PATCH] D147620: [DebugInfo] Keep the CU consistent for operating `DISubprogram`.

[DianQK via Phabricator via llvm-commits]

DianQK added inline comments.


================
Comment at: llvm/test/DebugInfo/Generic/cross-cu.ll:40-62
+!1 = distinct !DICompileUnit(language: DW_LANG_Rust, file: !2, producer: "clang LLVM (rustc version 1.70.0-nightly (ec2f40c6b 2023-03-30))", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !3, splitDebugInlining: false)
+!2 = !DIFile(filename: "src/lib.rs/@/3jkrl8oz9knrf4o4", directory: "/home/npopov/repos/test")
+!3 = !{}
+!4 = distinct !DICompileUnit(language: DW_LANG_Rust, file: !5, producer: "clang LLVM (rustc version 1.70.0-nightly (ec2f40c6b 2023-03-30))", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !3, globals: !6, splitDebugInlining: false)
+!5 = !DIFile(filename: "src/lib.rs/@/4r9uiw0o66d13q4b", directory: "/home/npopov/repos/test")
+!6 = !{!7}
+!7 = !DIGlobalVariableExpression(var: !8, expr: !DIExpression())
----------------
dblaikie wrote:
> DianQK wrote:
> > dblaikie wrote:
> > > OK, so from the description in the other inline comment - I take it you're dealing with the situation here, where:
> > > 
> > > `!23` (`DISubprogram` for `alloc::alloc::Global::alloc_impl`) is defined in CU `!1`
> > > `!8` that also, indirectly, references the type is in CU `!4`
> > > 
> > > Yeah, I think the bug here is that you shouldn't have member function definitions directly associated with DICompositeTypes - they should indirect through a declaration of the function.
> > > 
> > > Otherwise we'll inevitably end up in impossible situations - where we can't define the type in every translation unit that defines one of the member functions (or other references) to the type.
> > > 
> > > Types are intentionally not attached to a CU because they exist across the whole program - so we need to be able to reference them from anywhere/lazily create them in whatever CU we need, generally.
> > > 
> > > If you've got similar metadata from Swift, I'd like to take a look/talk to the Apple/Swift folks about this.
> > > 
> > > But, yeah, generally, I don't think this IR is OK/supportable as-is. It should have a declaration of the function - so that the function definition can appear in a CU distinct from the definition of the type. So the function definition can stay in the CU that defined it.
> > Thank you for clarifying the issue.
> > Maybe @aprantl could come and take a look at Swift?
> > 
> > I'm glad to check out the Rust-related implementation. I only know a little bit about Rust. It may take some time.
> > Do you think it is appropriate to submit this patch as a workaround? We can revert it before LLVM 17 is released.
> > This change does not appear to affect C++ debug info generation.
> I don't think it's suitable to commit as a workaround - but maybe other folks have other ideas/I wouldn't rule it out entirely.
> 
> If you're not especially familiar with Rust, what's your particular context for/interest in this bug?
> I don't think it's suitable to commit as a workaround - but maybe other folks have other ideas/I wouldn't rule it out entirely.
If we treat all such IR fixes as a workaround, I realize that D136039 is a vulnerable workaround. It corrects one CU and affects the CU of another case. But this issue does not occur with the current patch.
I have found that inconsistent CU can lead to several problems:
- **Invalid DWARF**: `no mapping for range`, `inconsistent range data`, and `could not find referenced DIE`.
- **Unable to generate target file**: `Cannot represent a difference across sections`.
After this patch, we will get **Valid but useless DWARF**. I think **Valid but useless DWARF** is better than **Invalid DWARF**, and **Invalid DWARF** is better than **Unable to generate target file** in these three bad cases. We can make a no-good IR work as well as possible. Here's what I think.
> But it may also be annoying for debugging.

---
> If you're not especially familiar with Rust, what's your particular context for/interest in this bug?
No special reason. I'm just a PL/compiler enthusiast. I improve my technical skills by solving some real problems. I didn't have the opportunity to get a comprehensive CS and PL education. So sometimes I may have weird conclusions and terminology (;△;).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147620