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

[Mehdi Amini via llvm-commits]

> 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