[LLVMdev] Using the unused "version" field in the bitcode wrapper (redux)

[Rafael Espíndola]

> Currently in the toolchain which we ship and support, we use a proprietary
> linker. That linker is unable to read bitcode files and we do not have any
> plans to enable it to as far as I’m aware. Because of this, we need a way of
> identifying the version of a bitcode file without needing to read/understand
> the bitcode itself. The bitcode wrapper is perfectly suited for this task as
> it is simple to parse without the linker needing to understand bitcode, is
> already defined and already includes a version field.

There are a few issues in this statement:

First: it is very specific to the current state of a specific toolchain.

Second: even in the specific case mentioned, the conclusion that the
version must readable without understanding bitcode seems a non
sequitur. The gold linker doesn't link with llvm and ld64 does so only
indirectly. The entire LLVM specific knowledge is placed in
LLVMgold.so or libLTO.dylib. Any linker that supports LTO with LLVM
will have a component or related tool that knows LLVM and could check
version information and raise the alarm. It must be able to report an
error because two GlobalVariables could not be merged, why is
producing an error on the version harder?

Third: even the conclusion that a version is needed seems a non
sequitur. The current policy gives us the *option* of dropping support
for old bitcode once we get to 4.1. That means that *if* we decide to
drop something, *and* that something cannot be easily identified by
the bitcode structure itself, *then* we will need to add a version
number in 4.0.

There can always be bugs, but we should just test for compatibility
and fix when issues are found.

>
>
> If we could get the compiler to use that version field that is already
> present, it would be a simple solution to our problem. So I guess my
> question is whether there is any objection to actually using a field which
> is already allocated for this kind of information?

As noted, the backwards compatibility guarantees that we offer require
all bitcode formats to be treated equally, so depending of the wrapper
for this is not a good idea.

Cheers,
Rafael