(ping.) > On Aug 10, 2015, at 5:03 PM, Adrian Prantl <apra...@apple.com> wrote: > > [resending because I accidentally sent this to the old mailing list]. > >> On Jul 24, 2015, at 12:33 PM, David Blaikie <dblai...@gmail.com >> <mailto:dblai...@gmail.com>> wrote: >> >> *reads back through the thread* > > appreciated, it’s long :-) > >> 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. > > 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. > >> 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. >> >> 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). >> >> 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)?) > > 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. > > 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). > > (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). > (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?). > > 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. > > -- adrian
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
