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

[Rafael Espíndola via llvm-commits]

On 9 September 2015 at 18:36, Chandler Carruth <chandlerc at google.com> wrote:
> Two points.
>
> One, we have the idea of backwards compat until a major version bump. If
> we're going to do this, we should write a record with the epoch of
> compatibility as a monotonically increasing integer IMO. It seems crazy to
> not have a way to check that the bitcode file is at least *plausible* to
> auto-upgrade. That seems reasonable for the open source project in general.
>
> Second, unless there is a pressing need to handle this in an opaque
> vendor-specific way, I'd love to find an approach that could even be useful
> to open source developers. Let me propose an alternative, and maybe you can
> tell me where it falls over: we could add both a hard compatibility epoch
> counter, and a version string. The version string would literally contain a
> munged string just like 'clang --version' does. We can stash SVN revisions,
> release numbers, and whatever else your heart desires in there. Then, when
> the bitcode reader fails for some reason, as part of a more helpful error
> message, we use these strings in the two bitcode files to try to form a
> helpful error message:
>
> "ld: Error parsing bitcode file in libFooBar.a (generated by LLVM rNNNN,
> read by LLVM rMMMM)" or some such.
>
> Thoughts?

I like the idea of an unstructured version string that is printed once
an error is found by some other way.

Note that we don't have to add the epoch right now, since its absence
can be read as epoch 0.

One issue with the epoch idea is that we would then be dropping big
version ranges at a time. Once we get to 4.1 we can choose to drop
compatibility with 3.X. If we want to drop with all of 3.X the epoch
works fine, but what if only revisions < 3.5 are problematic enough
that we want to drop it? Should the epoch be updated more often than
that?

Cheers,
Rafael