[clang] [llvm] [DebugInfo] Place local ODR-uniqued types in decl DISubprograms (PR #119001)

[Jeremy Morse via llvm-commits]

jmorse wrote:

Indeed @ the language, it's difficult to know that this is definitely going to work when I don't have a full understanding of the patch series, thus the caution,

I've studied a bit further and even with the full patch series we seem to be missing an important link. Here's a gist: https://gist.github.com/jmorse/091ae6ed42e6a36199b8593a7b81bd49 which contains the LLVM DWARF output for the aforementioned lexical-block-static-var.ll . While it passes the FileCheck lines in the test, it lacks the DW_AT_abstract_origin that gcc produces -- observe that nothing references addresses 8a or 5b. The consumer is then presumably left with a problem: it might be able to discover the static variables A and B, and that they're in a lexical block, but not _which_ lexical block. There's also a risk that I misapplied D144008, which I had to copy-and-paste out of Phab, @dzhidzhoev would you have a public-github branch that contains that patch?.

In the IR metadata, each DIGlobalVariable refers into a tree of distinct DILexicalScopes and DISubprograms that's part of the definition subprogram for the relevant function. I suspect that in scenarios where multiple instances of an inline function with a static variable are LTO'd, we might see a repeat of this type uniquing problem: LLVM will pick a single DIGlobalVariable as the location for such an inlined-function static variable, which will then refer into the DILexicalScope/DISubprogram tree for one instance of the inlined function, potentially causing confusion or hard-to-interpret DWARF. I think the natural solution to this is putting DIGlobalVariable scopes into a "declaration" tree of DILexicalScopes/DISubprograms too.

I'll try to cook up a precise example of this happening so that it's clear, but have to dash for now.

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