[LLVMdev] LTO type uniquing: ODR assertion failure

David Blaikie
Mon, 21 Jul 2014 20:14:18 -0000

On Mon, Jul 21, 2014 at 10:39 AM, Manman Ren <manman.ren at gmail.com>
wrote:
>
>
>
> On Mon, Jul 14, 2014 at 11:32 AM, Manman Ren <manman.ren at
gmail.com> wrote:
>>
>>
>> We still have access to types via MDNodes directly and the assertion
that
>> assumes all accesses to DITypes are accessing the resolved DIType will
fire
>>
>> i.e assert(Ty == resolve(Ty.getRef()))
>>
>> One example is the access to DIType via DIArray in SubroutineType. If
all
>> elements in the type array are DITypes we can create a DITypeArray and
use
>> that for SubroutineType's type array instead. But we currently have
>> unspecified parameter in the type array and it is not a DIType.
>
>
> I am going to work on a patch that adds DITypeArray (each element will be
> DITypeRef, SubroutineType's type array will be DITypeArray) and adds
> DITrivialType that extends from DIType (unspecified parameter will be
> DITrivialType).
> If you  have opinions against it, please let me know,

We haven't bothered using typed arrays in DebugInfo yet (as you say,
we just have DIArray) so I have two thoughts

1) why does this one case need fixing/changing? Is it because we have
things that aren't DIDescriptors inside the DIArray? (the strings that
refer to types). Given how loosely typed DIDescriptor is (it doesn't
check that it's a valid DIDescriptor) I assume this doesn't actually
cause a problem, though it's certainly not nice. So we could just
leave it as-is, pass DIArray's element to "resolve" (it'd
implicitly
convert the DIDescriptor back to a raw MDNode*), then perhaps we'd
need to make DITypeRef's ctor public so it could be used here. Not
suggesting that's ideal, though.

2) If we're going to fix DIArray apparent type safety (it's not safe -
just convenient), perhaps we could just template it? (to avoid churn,
we could leave DIArray as a typedef of DITypedArray<DIDescriptor> for
example, and then have DITypedArray<DITypeRef> which is your
DITypeArray (again, provided via typedef)). It's so small though, that
I'm not too fussed if we write it out again as you've proposed.

- David

>
> Thanks,
> Manman
>
>>
>> What are your thoughts? Suggestions are welcome.
>>
>> Is it a good idea to canonicalize file names (i.e dA/B.h should be
>> equivalent to dA/../dA/B.h)? This will reduce the chance of having two
>> DITypes that should be equivalent with equivalent file names.
>>
>> Thanks,
>> Manman
>
>