[PATCH] Add a DIExternalTypeRef debug metadata node to the IR.

[David Blaikie]

On Fri, May 8, 2015 at 2:38 PM, Adrian Prantl <aprantl at apple.com> wrote:

>
> > On May 8, 2015, at 1:00 PM, Duncan P. N. Exon Smith <
> dexonsmith at apple.com> wrote:
> >
> >
> >> On 2015 May 8, at 15:32, David Blaikie <dblaikie at gmail.com> wrote:
> >>
> >>
> >>
> >> On Fri, May 8, 2015 at 11:18 AM, Adrian Prantl <aprantl at apple.com>
> wrote:
> >> Hi dexonsmith, dblaikie, echristo,
> >>
> >> This adds a DIExternalTypeRef debug metadata node to the IR that is
> meant to be emitted by Clang when referring to a type that is defined in a
> .pcm file. DIExternalTypeRef is a child of DICompositeTypeBase because it
> shares common traits such as the unique identifier.
> >>
> >> Could this be an attribute to the DIClassType/StructureType? (to emit
> the currently needed type unit references, we still should know the correct
> class/structure type tag) LLVM already knows to hash the ref identifier
> (mangled name) for the type unit identifier.
>
> Note that DIExternalTypeRef also knows the tag.
>

OK. Though I'm still unclear on the advantage of this over just making this
essentially another kind of type declaration... (heck, I've wondered if we
could just do this by default: if type units are enabled and we're emitting
a type declaration for a type with a the ref identifier, just emit it as a
type unit - but I guess that won't solve the issue of using module debug
info but not using type units generally (would still need the flag to
describe that this type needs to be a type ref, not a plain declaration))


> >
> > I think they should be separate for now.  When we have an
> > `identifier:` field in `DICompositeType` we use the
> > string-based `DITypeRef`s instead of direct pointers.  I don't
> > imagine there's any value in adding that indirection for these.
>
> It would make lookups slower, but otherwise it would be harmless.
>
> > (Although, this makes me wonder about an LTO scenario.  Imagine you
> > have two translation units, and they both use a type identified by
> > (e.g.) "my-type".  One of them pulled the type in from a module
> > and has a `DIExternalTypeRef`, while the other translation unit
> > didn't use modules and has a `DICompositeType`.  What should the
> > debug info look like?  Is it okay if we end up with both?  If not,
> > which one should win?
>
> This is a scenario that can only happen in C++. For maximum space
> efficiency you would want the external type ref to win or you will end up
> with two copies of the type (which isn’t otherwise harmful). If you are are
> using dsymutil, it will still unique the two copies.
>
> >  Will these new nodes show up in the
> > `retainedType:` list?)
>
> They will not show up in the retained types list.
>
> >
> > Another couple of questions to decide whether to make a new node:
> >
> > 1. Will the backend logic be essentially the same for the two, or
> >    would we have disjoint handling?
>
> There is different backend handling for LLDB and GDB.
>
> > 2. Is this a reasonable target for a 'scope:' field?  (If not, I
> >    think they should be distinct.)
>
> We could attach the Skeleton compile unit but there is no real need for
> it. Making them distinct sounds fine for me.
>
> -- adrian
> >
> >
> >>
> >> - David
> >>
> >>
> >> The idea how this is going to be used is that the frontend will
> discover that a type originates from an AST file and instead of and
> constructing a full DIType (and thus deserializing the type from the AST)
> it creates a DIExternalTypeRef with the tag type, mangled name and the .pcm
> file. The backend then can emit this as a split-DWARF-style forward
> declaration using DW_FORM_ref_sig8 (GDB) or as a string reference (LLDB) +
> and accelerator table entry.
> >>
> >> REPOSITORY
> >>  rL LLVM
> >>
> >> http://reviews.llvm.org/D9612
> >>
> >> Files:
> >>  include/llvm/Bitcode/LLVMBitCodes.h
> >>  include/llvm/IR/DIBuilder.h
> >>  include/llvm/IR/DebugInfoMetadata.h
> >>  include/llvm/IR/Metadata.def
> >>  include/llvm/IR/Metadata.h
> >>  lib/AsmParser/LLParser.cpp
> >>  lib/Bitcode/Reader/BitcodeReader.cpp
> >>  lib/Bitcode/Writer/BitcodeWriter.cpp
> >>  lib/IR/AsmWriter.cpp
> >>  lib/IR/DIBuilder.cpp
> >>  lib/IR/DebugInfoMetadata.cpp
> >>  lib/IR/LLVMContextImpl.h
> >>  lib/IR/Verifier.cpp
> >>  test/Assembler/DIExternalTypeRef.ll
> >>
> >> EMAIL PREFERENCES
> >>  http://reviews.llvm.org/settings/panel/emailpreferences/
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150508/9b3fc685/attachment.html>