[llvm-dev] [RFC] Lazy-loading of debug info metadata

[Adrian Prantl via llvm-dev]

> On Apr 18, 2016, at 8:08 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> <snip>
> 
> I'm also concerned about the semantics of a particular case that I
> learned debugging correctness issues.  If a type is defined inside a
> function, we create a DICompositeType (CT) whose "scope:" is the
> DISubprogram (SP) for that function's definition.  This SP is not part of
> the type graph, it's the actual definition that eventually describes the
> code.
> 
> However, the CT has an ODR identifier, which means it will get uniqued
> by the DITypeMap.  This seems wrong.  If the function is defined in a
> header you can end up with two copies of this type, and their scope is
> completely unrelated.  Here it is without using the type map:
> --
> !0 = distinct !DICompileUnit()
> !1 = distinct !DISubprogram(name: "foo", unit: !0)
> !2 = distinct !DICompositeType(name: "T", identifier: "foo_T", scope: !1)
> !3 = distinct !DICompileUnit()
> !4 = distinct !DISubprogram(name: "foo", unit: !3)
> !5 = distinct !DICompositeType(name: "T", identifier: "foo_T", scope: !4)
> --
> 
> I had thought that when !DICompositeType had an 'identifier:' (followed
> ODR-rules) then its 'scope:' must also have an 'identifier:', or at least
> follow ODR-rules.  That's clearly not always the case right now.  There
> are two simple ways to make it so:
> 
>  1. Drop the 'identifier:' from composite types local to a subprogram.
> 
>  2. Change the 'scope:' to point at a *declaration* of the subprogram
>     (which lives in the type graph) and unique them there (and disallow
>     having 'identifier:' types point at subprogram definitions).

Intuitively option (2) seems to be the better solution — we want to separate out the type hierarchy from the function definitions. In the  spirit of PR27352[1], could we even stop DISubprograms from being DIScopes in the class hierarchy and use uniqueable DIPrototypes as scopes instead?

-- adrian

[1] https://llvm.org/bugs/show_bug.cgi?id=27352
> 
> I'd appreciate feedback on whether either of these is a good idea.
> 
> (Another way of looking at this, is that I'd imagined there were two
> parts of the debug info graph: the "types" part, and the "codegen" part
> (by which I mean stuff that describes the actual emitted object code);
> and I'd imagined that the "types" part never referenced the "codegen"
> part.  However it does in this case.)