[PATCH] Have clang list the imported modules in the debug info

[Adrian Prantl]

> On May 6, 2015, at 2:52 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Wed, May 6, 2015 at 2:45 PM, Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
> 
>> On May 6, 2015, at 2:35 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote:
>> 
>> 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).
> 
> I suppose one could hash the entire module configuration + the mangled name and get something that is relatively stable.
> 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.
> 
> 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.

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.

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150506/64a84b65/attachment.html>