[PATCH] Wire up external debug type references in LLVM

[Adrian Prantl]

> On Jul 14, 2015, at 1:37 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Tue, Jul 14, 2015 at 12:13 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> Hi Eric & David,
> 
> this patch implements bare-bones LVM support for external type references as previously discussed in http://reviews.llvm.org/D9612 <http://reviews.llvm.org/D9612>.
> This is a necessary prerequisite for bootstrapping the emission of debug info inside modules.
> 
> - Add a FlagExternalTypeRef to DICompositeType. External types must have a unique identifier.
> - External type references are emitted in the short form DW_AT_type([DW_FORM_ref_sig8]) but the long form with an indirect reference is also supported (see test case for examples).
> 
> Knee-jerk reaction (haven't looked at the patch yet): Long form will be necessary for all the implicit things (you won't know which implicit things go in the module debug info, because you can't instantiate them ahead of time - well, maybe you can in a SFINAE trap... - but then there's still member function template implicit specializations and nested classes).
> It might be best to implement the general form first, then look at an optimization for the "has no children" case separately (& in a way that applies to normal type unit references too)
That would be easy, we just cut the 4 lines that emit the short form from the patch :-)

> 
> What happens for that today? (I see you have a nested imported declaration that's forcing the emission of the type declaration, I take it? What happens if the type is also referenced separately - does it get a sig8 there too, or does it use the 4 byte section offset to refer to the type declaration which has the sole sig8?)

With this patch we would end up with a sig8 in the AT_type and an AT_signature in the forward declaration. Emitting a ref4 to the declaration is actually tricky because the entity that triggers the creation of the forward declaration may not have been visited yet.

I think you’re right that it would be safer to just always emit the long form and treat the short form as an optimization left for later.

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150714/eb0c18ca/attachment.html>