[llvm-dev] [RFC] Lazy-loading of debug info metadata
Adrian Prantl via llvm-dev
llvm-dev at lists.llvm.org
Mon Apr 18 08:33:30 PDT 2016
> On Apr 18, 2016, at 8:08 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
> 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
> 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, could we even stop DISubprograms from being DIScopes in the class hierarchy and use uniqueable DIPrototypes as scopes instead?
> 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.)
More information about the llvm-dev