[LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication
Manman Ren
manman.ren at gmail.com
Wed Oct 16 21:13:20 PDT 2013
On Wed, Oct 16, 2013 at 2:00 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Wed, Oct 16, 2013 at 1:33 PM, Manman Ren <manman.ren at gmail.com> wrote:
>
>>
>>> patch looks fairly obvious/trivial
>>>
>>> Have you tried any of the test cases I've described (special members,
>>> nested types, and member templates - all used across CUs so an earlier CU
>>> has the type definition and a latter one has one of these extra members)?
>>> I'd like to see test results for these before we progress.
>>>
>>
>> Yes, templates and nested types where we have two MDNodes for the same
>> class, and one has an extra member.
>>
>
> Could you include the tests (or at least in a separate patch if you think
> they're so uninteresting as to possibly not be needed with your change)?
>
> I'd be interested to see how you constructed/tested them, which order the
> CUs came in, how the mismatch was resolved, etc.
>
Sure, I can add the testing cases in a separate patch.
>
>
>> They work fine with the patch (no assertion failure).
>>
>
> I'm interested in more than just the absence of assertions. (or are you
> referring to the kind of assertion machinery we've touched on in this
> thread but I haven't seen your code for - in which we keep a mapping of
> assumptions and verify those assumptions when a DIE is added to its parent
> and the assumption is resolved?)
>
I was referring to the assertion that when emitting ref4, the DIE and the
referenced DIE belong to the same CU (i.e. we made the right
decision about the reference form inside addDIEEntry).
Thanks,
Manman
>
> - David
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131016/ac5377d7/attachment.html>
More information about the llvm-dev
mailing list