[LLVMdev] [Debug Info PATCH] for support of ref_addr and removal of DIE duplication

David Blaikie dblaikie at gmail.com
Wed Oct 16 22:22:23 PDT 2013


On Wed, Oct 16, 2013 at 9:13 PM, Manman Ren <manman.ren at gmail.com> wrote:

>
>
>
> 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.
>

I'd like to see the tests before the patch is committed (at which point
they might as well be committed along with the 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).
>

But none of your patches have the code necessary to check this assertion
while not using a worklist, do they? so how does "no assertion failures"
mean "we used the right form"?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131016/d8b4f902/attachment.html>


More information about the llvm-dev mailing list