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

I just filed this as pr17982, but I'd like to call attention to it, since it
seems like something we should try to fix in the 3.4 release.

Here's the description from the PR:

Sometime over the last year, and I'm fairly certain it has been since we
released 3.3, the debug info metadata format has changed in incompatible ways. 
If you try to use an older bit code file with the current compiler, it is not
uncommon for the compiler to crash.  This goes against our goals for keeping
backward compatibility for bit code files and is especially problematic for LTO
since you can't reliably mix objects from different versions of clang.

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.

I don't have a test case but we should be able to come up with one if
needed.

I agree that this really needs to be fixed before 3.4...
On Mon, Nov 18, 2013 at 9:56 AM, Bob Wilson <bob.wilson at apple.com>
wrote:
> Sometime over the last year, and I'm fairly certain it has been since
we
> released 3.3, the debug info metadata format has changed in incompatible
> ways.  If you try to use an older bit code file with the current compiler,
> it is not uncommon for the compiler to crash.  This goes against our goals
> for keeping backward compatibility for bit code files and is especially
> problematic for LTO since you can't reliably mix objects from different
> versions of clang.
>
I don't think that you need LTO for this to be a problem. The bitcode
really has to be readable by future versions of LLVM.

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

>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131118/b4df7b12/attachment.html>

Hi Bob,

On Mon, Nov 18, 2013 at 9:56 AM, Bob Wilson <bob.wilson at apple.com>
wrote:
> I just filed this as pr17982, but I'd like to call attention to it,
since it seems like something we should try to fix in the 3.4 release.
>
> Here's the description from the PR:
>
> Sometime over the last year, and I'm fairly certain it has been since
we released 3.3, the debug info metadata format has changed in incompatible
ways.  If you try to use an older bit code file with the current compiler, it is
not uncommon for the compiler to crash.  This goes against our goals for keeping
backward compatibility for bit code files and is especially problematic for LTO
since you can't reliably mix objects from different versions of clang.
>
> 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.
>
This is not going to be fixed.

Metadata formats are not guaranteed to be stable and this has been an
explicit design factor. The versioning support was removed many months
ago and the debug info format has been moving quickly. This has been
stated many times on list, in discussion, and with patches.

http://llvm.org/viewvc/llvm-project?rev=176838&view=rev

is the revision where the versioning, that didn't work anyhow, was
finally removed back in March.

Once the verifier works better it can discard debug metadata that
fails verification if we'd like to go that route.

-eric

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