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

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 24 17:42:55 PDT 2023


dblaikie 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())
----------------
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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147620



More information about the llvm-commits mailing list