<div dir="ltr">*reads back through the thread*<br><br>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><br>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><br>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><br>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><br>- Dave</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 6, 2015 at 3:43 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On May 6, 2015, at 3:24 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 6, 2015 at 3:15 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><span><div>On May 6, 2015, at 2:52 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br></span><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, May 6, 2015 at 2:45 PM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><span><blockquote type="cite"><div>On May 6, 2015, at 2:35 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:</div></blockquote></span></span><span><span><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>That said, add enough to the name for hashing purposes to make it hash uniquely? Or you can go down the path of hashing the type similar to the fission CU hashing (which is what type units were arguably designed to do in the first place if you take a look at the standard, we just only use them for ODR compliant languages etc right now).</div></div></div></div></blockquote><div><br></div></span><div>I suppose one could hash the entire module configuration + the mangled name and get something that is relatively stable.</div><div>For implementation reasons it would be terrible to do the full fission hashing because that would mean that we would actually have to look up (and deserialize the type) in order to get to its ID when emitting an external type reference, which would void at least some of the performance gains we want from module debugging.</div></span></div></div></blockquote><span><div><br>I thought you were proposing using the mangled name of the type for the identifier anyway? Perhaps I misunderstood - what are you proposing to use? In any case, I'd prefer to see whatever it is hashed and used as the type unit signature for compatibility with DWARF5, rather than adding an extra/separate/new/non-standard way to do cross-unit/cross-fission type references.<br></div></span></div></div></div></div></blockquote><div><br></div><div>In the IR I’d /like/ to have a DIExternalTypeRef(DW_TAG_class_type, !”_ZTC6TypeName”, !1) with !1 being a reference to either the DIModule or the skeleton CU. Then the backend would emit the hash of the name if type units are enabled (C++/gdb) or the mangled name (+ the accelerator table entry) otherwise (ObjC and/or Darwin). If there is significant pushback to the latter, I’d be willing to have the backend emit a hash in both cases but we’d have to careful about what to exactly to hash for all the aforementioned reasons.</div></div></div></blockquote><div><br>I don't follow - if the mangled name is sufficient, then a hash of the mangled name should be.... what am I missing?<br><br></div></div></div></div></div></blockquote></span><div><div>Nothing, these are two separate issues:</div><div><br></div></div><span class=""><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>If you don't have an ODR to rely on, then a mangled name seems insufficient just as the hash would be.<br></div></div></div></div></div></blockquote><div><br></div></span><div>The decision for mangled name vs hash is motivated by the mangled name also doubling as a key to look up the type in the AST.</div><div>The other problem is (partially) solved by the accelerator table entry that associates the mangled name with a module. I’m starting to think now that it might be better to include a fission-style forward declaration + decl context into the TAG_module instead. The DWARF-style decl context could in theory be smaller than the mangled name because two types could share common ancestors and then we could emit the same hash of the mangled names as we do for type units. But let’s discuss this when it comes up (together with the patch that makes use of DIExternalTypeRef).</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- adrian</div><div><br></div></font></span></div></div></blockquote></div><br></div>