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

[Chandler Carruth via llvm-commits]

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?

On Wed, Sep 9, 2015 at 3:24 PM Mehdi Amini via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

>
> > On Sep 8, 2015, at 11:30 AM, Rafael Espíndola <
> rafael.espindola at gmail.com> wrote:
> >
> >>> ./bin/llvm-dis: error: unknown linkage number 20. Input is likely from
> >>> a newer llvm version.
> >>
> >> This error is useful to compiler engineers, but probably not to our
> >> customers.
> >>
> >> We want to be able to say something along the lines of:
> >> --
> >> error: cannot read bitcode generated from newer clang (800.0.64)
> >> --
> >> where 800.0.64 is a hypothetical future Apple clang version that's
> >> embedded somehow (but predictably) in the bitcode it produces.
> >
> > So, printing the producer version does require it being written
> > somewhere in the bitcode. It then comes down to the cost/benefit of
> > it.
> >
> > In previous discussions about having a version number, I think the
> > main objections were
> >
> > * Using the bitcode wrapper instead of the bitcode proper (doesn't
> > apply to this patch).
> > * The use of the version number for backwards compatibility checking.
> > The previous patches would add a version that would be known and
> > handled by the open source tools, it would then be just too easy to
> > start using it for compatibility instead of the current practice of
> > making the local structure self sufficient.
> >
> > The second concern also doesn't apply directly to this patch, as long
> > as we make sure trunk always ignores VENDOR_RESERVED_ID.
> >
> > In summary. I am OK with this, but please
> > * Make sure including the future version number in the error is really
> worth it.
> > * Put a comment saying VENDOR_RESERVED_ID should always be ignored in
> > the open source project.
> > * Get at least one extra LGTM (Nick, Chandler?)
> >
> > Another think, should we have a vendor ID enum and define the format
> > of VENDOR_RESERVED_ID to always start with the vendor ID? That would
> > avoid, for example, apple tools trying to read unrelated scea data as
> > a clang version.
>
> I thought about that but I’m unsure how you can do it without specifying
> the format.
> Are you thinking about just "asking" that implementors to always put a 32
> bits vendor_id as the first record in the block?
>
> My internal prototype is using a “magic” at the beginning of the block.
>
> Thanks,
>
> —
> Mehdi
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150909/e6dad767/attachment.html>