[PATCH] D12618: Reserve a vendor reserved block ID for bitcode

[Mehdi Amini via llvm-commits]

> On Sep 4, 2015, at 8:43 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> 
> > Our current issue is not reading old bitcode but what to do with new bitcode.
> >
> > For instance you install a beta version of Xcode, build a project with LTO, and then revert Xcode to the previous version.
> > At this point the bitcode on your disk is too new for your installed toolchain and a non-clean build may crash libLTO.
> 
> That is a bug in llvm. It should never crash on any input. A newer bitcode is just a special case.
> 
We just had a case with "ld: could not reparse object file ./libXXXX.a): 'Invalid record', using libLTO version 'Apple LLVM X.X.X (clang-X.X.X)' for architecture XYZ”. For two versions pretty close (<1y). 

What about when LLVM 4.0 will be here? What if some 4.0 bitcode is fed through LLVM 3.8?

Even if we don’t crash on the Bitcode *format*, which shouldn’t really happen, what about the optimizer generating intrinsics that are not supported by the backend? Admittedly the latter can be solved with global metadata.

Also, we are branching at different interval than open-source LLVM, so the guarantee on the bitcode from a version to another might be harder to enforce (cf the message above).


> I am confident we can get there by fuzz testing.
> 
Good idea!

> > Another case is when some people distribute static archive that contains bitcode. Right now we end-up with terrible crash reports while we want to improve user experience with great diagnostics.
> 
> With what we have in trunk we should be able to implement errors like:
> 
> Error: unknown linkage number XX. Input is likely from a newer llvm version.
> 
> Would that be sufficient?
> 

Possibly, can you point me to the mechanism involved here?

— 
Mehdi


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150904/328aec2b/attachment.html>