[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
