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

[Manman Ren]

On Tue, Nov 19, 2013 at 8:47 PM, Manman Ren <manman.ren at gmail.com> wrote:

>
>
>
> On Tue, Nov 19, 2013 at 5:26 PM, Manman Ren <manman.ren at gmail.com> wrote:
>
>>
>>
>>
>> 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.
>>>
>>
>> Adding a debug info version number and ignoring the debug info MDNodes
>> when version does not match makes sense. And changing the version number
>> with every release sounds reasonable.
>>
>> One implementation is
>> 1> completely get rid of version number in the tag
>>   LLVMDebugVersion is only used in two places and we should be able to
>> remove it.
>>     include/llvm/DebugInfo.h:    return getUnsignedField(0) &
>> ~LLVMDebugVersionMask;
>>     lib/IR/DIBuilder.cpp:  assert((Tag & LLVMDebugVersionMask) == 0 &&
>>     lib/IR/DIBuilder.cpp:  return
>> ConstantInt::get(Type::getInt32Ty(VMContext), Tag | LLVMDebugVersion);
>>   I remember there was something that blocks David from completely
>> getting rid of version number, but it seems the blocker is gone now.
>>   This can be done separately as well.
>>
>> 2> introduce a debug info version in module flags similar to "dwarf
>> version" module flag
>>      LTO can correctly handle the module flag during linking and we only
>> need to change one line in the debug info testing cases when we update
>> debug info version number.
>>      One issue is that we don't have a mode that emits a warning and
>> outputs the largest value (we have a mode that emits a warning and outputs
>> the value from the first module, but we can definitely add another mode if
>> necessary)
>>
>> 3> when to drop the debug info MDNodes?
>>      We could do this in the bit code loader but it seems a violation of
>> layers. One possibility is to run a module pass right after loading the bit
>> code, to remove debug intrinsics and debug tags on instructions.
>>
>
> We have an existing pass StripSymbols that can strip debug info in the
> module.
> So it is just a matter of adding that pass after bit code loader if the
> debug info version number does not match.
>

Can I assume no objection to the approach? :)
Bill, are you okay with adding another mode to module flags? i.e. emits a
warning and outputs the largest value.

Thanks,
Manman


> 4> how to report warning?
>     Is errs() << "WARNING: " good enough? BTW this is how we emit warning
> when linking module flags.
>
> Any objection to the above? Any other suggestion?
>
> Thanks,
> Manman
>
>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131121/0b3d5562/attachment.html>