[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