[LLVMdev] bit code file incompatibility due to debug info changes

[Eric Christopher]

On Mon, Nov 18, 2013 at 11:00 AM, Chandler Carruth <chandlerc at google.com> wrote:
>
> On Mon, Nov 18, 2013 at 10:55 AM, David Blaikie <dblaikie at gmail.com> wrote:
>>
>> It depends a bit, also, on what kind of guarantees we need to offer. If
>> the guarantee when reading IR from disk is "will not crash" then there's
>> nothing for it but to run full debug info verification.
>>
>> On the other hand, if we can assume that some specific metadata implies
>> the correctness of some other metadata, then all we need to do is check a
>> known debug info version number. If it's the current number, do nothing
>> (assume the rest of the debug info is up to date and well formed), otherwise
>> do all the work to find the debug info and dump it (no need to verify it -
>> we just have to do the work to find it, so we don't go following bad links
>> later on - that should be as easy as dropping the llvm.dbg.cu named node and
>> removing all debug intrinsics and the instruction metadata line references).
>> But this latter scheme isn't robust against arbitrary metadata (that could,
>> coincidentally, have the right version number and arbitrary metadata that
>> breaks all our debug info metadata assumptions)
>>
>> If the latter is sufficient for everyone's needs/principles, great.
>
>
> This makes sense to me, but I see Eric's fundamental concern with upgrading
> test cases.
>
>
> One other possible idea: we could artificially force coarseness on metadata
> while things are still iterating rapidly by just having a version number
> that rotates every "release". (Even non-open-source-releases could be
> handled by letting anyone, any time they need to rev it, update what the
> current version is and update every test case to reference that version.) If
> the version is nicely factored, it should at least be an obvious diff if
> still huge.

That could work, it'd be a simple script to say "update all of the
debug info testcases to move to the new version" between versions but
it probably wouldn't be too bad. Part of the branch cut.

-eric