llvm dev - Nov 2013 - [LLVMdev] bit code file incompatibility due to debug info changes

>>
>> At a minimum, it seems like we need a version number in the debug info
>> metadata so we can detect this situation and avoid crashing.
>
>
> Or to put it in the terms of the IR: we need to autoupgrade the debug info
> metadata just like we do intrinsics. With debug info this might (at the
> worst) involve dropping old metadata.
>
The verifier is probably the best route here. I think if we fail debug
info verification we can just strip it and continue.

-eric
>>
>>
>> I don't have a test case but we should be able to come up with one
if
>> needed.
>
>
> I think doing so would be useful.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On Mon, Nov 18, 2013 at 10:35 AM, Eric Christopher <echristo at
gmail.com>wrote:
> >> At a minimum, it seems like we need a version number in the debug
info
> >> metadata so we can detect this situation and avoid crashing.
> >
> >
> > Or to put it in the terms of the IR: we need to autoupgrade the debug
> info
> > metadata just like we do intrinsics. With debug info this might (at
the
> > worst) involve dropping old metadata.
> >
>
> The verifier is probably the best route here. I think if we fail debug
> info verification we can just strip it and continue.

I'm slightly worried about relying on verification based
"autoupgrade"
(where by upgrade I mean discard old cruft since it doesn't impact
correctness) due to compile time costs, but if the verification is fast
enough to be "always on", then cool.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131118/e5d344f0/attachment.html>

On Mon, Nov 18, 2013 at 10:37 AM, Chandler Carruth <chandlerc at
google.com> wrote:
>
> On Mon, Nov 18, 2013 at 10:35 AM, Eric Christopher <echristo at
gmail.com>
> wrote:
>>
>> >> At a minimum, it seems like we need a version number in the
debug info
>> >> metadata so we can detect this situation and avoid crashing.
>> >
>> >
>> > Or to put it in the terms of the IR: we need to autoupgrade the
debug
>> > info
>> > metadata just like we do intrinsics. With debug info this might
(at the
>> > worst) involve dropping old metadata.
>> >
>>
>> The verifier is probably the best route here. I think if we fail debug
>> info verification we can just strip it and continue.
>
>
> I'm slightly worried about relying on verification based
"autoupgrade"
> (where by upgrade I mean discard old cruft since it doesn't impact
> correctness) due to compile time costs, but if the verification is fast
> enough to be "always on", then cool.
Agreed, it's not really that fast either. The problem with versions is
that it makes small changes that only require a bit of modification to
the testcase to be pretty heinous upgrade paths and a lot of work -
you can see that from the work any of us have had to do when changing
the format. We'd like to keep the testcases and upgrade those as well
because otherwise we're just dropping testcases like mad constantly.
It's a lot of work, but the format has been changing frequently enough
that we'd be on version 1000 or something by now and it wouldn't
really accomplish much. The verifier seems to be the best route for
that. It isn't too fast, but then reading in bitcode files from disk
isn't particularly speedy either.

-eric