
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">[resending because I accidentally sent this to the old mailing list].</div><br class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 24, 2015, at 12:33 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">*reads back through the thread*<br class=""></div></div></blockquote><div class=""><br class=""></div>appreciated, it’s long :-)</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">So what I originally had in mind about a year ago when we discussed this, was that the module data could have an extra table from type hash to whatever useful internal representation to find the type in the PCM.<br class=""></div></div></blockquote><div class=""><br class=""></div>It turned out that the most useful internal type representation to find a type in a PCM is the type’s DeclContext+Name; this is how (surprise!) clang looks up types in a PCM and the format is supposed to be fast for these kind of lookups.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Everything else would just be DWARF with type units and fission (with the slight wrinkle of type units that aren't resolvable within a single object file - they could reference cross-object/dwo file) - emitting a fission CU for each referenced module.<br class=""><br class="">Needing modules to disambiguate/avoid collisions/support non-odr languages wasn't something I understood/had considered back then. That explains the need to add module references to the CU, so the debugger can know which modules to search for the types in (& doesn't just go loading all of them, etc).<br class=""><br class="">I would still picture this as "normal type units + a table in the module to resolve types", but if you guys particularly like using the mangled string name (or other identifier) in the DWARF that may avoid the need for an intermediate table (but it doesn't sound like you are avoiding an intermediate table - you said something about having an accelerator-table-like thing to aid in the DWARF->AST mapping? So could that be key'd of the type hash/signature we're using, thus keeping the DWARF more plain/vanilla DWARF5 (type units + fission)?)<br class=""></div></div></blockquote><div class=""><br class=""></div><div class=""><div class="">I originally disliked type signatures and favored using mangled names because the mangled names contained the DeclContext necessary to find types in the PCM. But if we can squeeze the DeclContext somewhere else, that’s fine.</div><div class=""><br class=""></div><div class="">From the discussion we had on FlagExternalTypeRef I got the impression that long-form forward declarations are starting to look more attractive: If every external type reference is a reference to a forward declaration that has a complete decl context, with a DW_TAG_module at the root of the decl context chain, and a DW_AT_name+DW_AT_signature at the other end, we would have all the information we need without introducing any further LLVM-specific DWARF extensions. To look up an external type from the PCM, the consumer imports the DW_TAG_module and deserializes the type found by declcontext+name. To load the type from DWARF, the consumer grabs the signature from the forward declaration and magically (1) finds the PCM and looks up the type by signature (2).</div></div><div class=""><br class=""></div><div class="">(1) My suggestion is to extend LLVM so it can put the DW_TAG_module with the forward declaration inside the skeleton compile unit (which has the path to the PCM and its DWOid).</div><div class="">(2) On ELF with type units this works out of the box, on MachO without type units we need some kind of index mapping signature -> DIE (bag of DWARF style?).</div><div class=""><br class=""></div>Assuming that many external types will share a similar DeclContext prefix I am not very worried by the space needed to store the long forward references. Compared to storing the mangled name for every type it will often actually take up less space. Also, on Darwin at least, llvm-dsymutil can strip them out of the way after resolving the external type references.</div><div class=""><br class=""></div><div class="">-- adrian</div></div></body></html>