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

David Blaikie dblaikie at gmail.com
Wed May 6 15:24:31 PDT 2015


On Wed, May 6, 2015 at 3:15 PM, Adrian Prantl <aprantl at apple.com> wrote:

>
> 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> wrote:
>
>>
>> On May 6, 2015, at 2:35 PM, Eric Christopher <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.
>

I don't follow - if the mangled name is sufficient, then a hash of the
mangled name should be.... what am I missing?

If you don't have an ODR to rely on, then a mangled name seems insufficient
just as the hash would be.


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


More information about the cfe-commits mailing list