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

[David Blaikie via llvm-dev]

On Mon, Apr 18, 2016 at 8:33 AM, Adrian Prantl <aprantl at apple.com> wrote:

>
> > 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?
>

I think that's going to produce some pretty weird DWARF I wouldn't expect
existing debuggers to handle well - I doubt they're necessarily equipped to
expect to see things like that in subprogram declarations & to merge them
appropriately with the contents of the definition. (and what if the type is
 in a local lexical scope in the function definition - do we put lexical
scopes in the declaration? (how do we then describe which part of the
function that lexical scope applies to? (which instruction range is the
type name valid for)))

Removing uniquing from these wouldn't work (imagine a local type in an
inline function in a header - lots of definitions of the function and its
associated type) - if the type was only used locally, maybe - but the type
could leak out into a template instantiation, and we could pick the wrong
one (we could pick the outer function from TU1 and the template
instantiation from TU2) potentially? Thus ending up with both/multiple
instances of the type, or deduplicating in a problematic way that leads to
both versions of the outer function (the one from TU1 and TU2)

I'm not sure yet what a good answer might be here


>
> -- 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.)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160418/95bf8d9d/attachment-0001.html>