[PATCH] D12618: Reserve a vendor reserved block ID for bitcode
Mehdi Amini via llvm-commits
llvm-commits at lists.llvm.org
Wed Sep 9 15:24:08 PDT 2015
> 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
>> 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
> 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.
More information about the llvm-commits