Processing bitcode from a different LLVM version can lead to unexpected behavior. The LLVM project guarantees autoupdating bitcode from a previous minor revision for the same major, but can't make any promise when reading bitcode generated from a either a non-released LLVM, a vendor toolchain, or a "future" LLVM release.
This patch aims at being more user-friendly and allows a bitcode produce to emit an optional block at the beginning of the bitcode that will contains an opaque string intended to describe the bitcode producer information.
The bitcode reader will dump this information alongside any error it reports.
Details
Diff Detail
Event Timeline
I wonder if this should have two components, one for the epoch and one for the string? I'm worried about the fact that you're using the only "unused" ID here, and it does seem nice to not use two IDs for this kind of data.
Is it possible to add a test for this, perhaps by forcing bad bitcode into llvm-dis?
$ llvm-as -disable-verify -o - | llvm-dis define void @f() { %1 = alloca i32 %1 = %1 ret void } llvm-as: <stdin>:3:8: error: expected instruction opcode
Seems like we could have a check-line here for the message BitcodeReader::error emits.
The problem is to be able to generate some invalid bitcode that *still contains the identification block*.
I tried with some valid bitcode: echo "randomstring" >> /tmp/bitcode.bc ;
But it is not enough to trigger an error with: llvm-dis /tmp/bitcode.bc
—
Mehdi
Most of my comments are pretty high-level. I'd imagine Duncan is in a much better position to check the actual bitcode side of it. =]
include/llvm/Bitcode/LLVMBitCodes.h | ||
---|---|---|
37–41 | Stale comment? Also "Can be used to provide better error messages when we fail to parse a bitcode file." maybe? | |
56–61 | Is there a better name here than "identification"? I'm not coming up with one... Any ideas Duncan? | |
63–68 | I would start at 0 and define missing == 0. I would also document that property. I think we should also spell out in a bit more detail that this is rev-ed with the major version of LLVM. Nits: | |
lib/Bitcode/Reader/BitcodeReader.cpp | ||
278–280 | It also does basic Epoch enforcement... | |
3116 | Can we provide a bit more detail here, much like you do above? |
Change the epoch to encode major.minor.patch. The basic compatibility check becomes (for now):
!((Major < LLVM_VERSION_MAJOR && LLVM_VERSION_MINOR != 0) || Major > LLVM_VERSION_MAJOR || (Major == LLVM_VERSION_MAJOR && Minor > LLVM_VERSION_MAJOR))
lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
3121 | Minor > LLVM_VERSION_MAJOR should be: Minor > LLVM_VERSION_MINOR |
lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
3121 | In irc we talked about how to test this... I'll capture those thoughts here: 9:06:40 PM - jokereph_: jroelofs: thks for spotting it 10:04:06 PM - jroelofs: jokereph: after thinking about it some more, I think the right thing to do testing-wise is to save off a bitcode file from each time the epoch changes, and then have a lit test that tries to load up each of these files. then check for the expected error message for each file |
lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
3122 | Android builder is failing because of unsupported std::to_string - http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-buildserver/builds/2835/steps/build%20android/logs/stdio |
lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
3122 | Sure, but do we know what makes it missing? The log says gcc 4.9.0, what is the C++ library used? |
lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
3122 | Twine(Major) would work here. |
lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
3122 | Android NDK uses own version of STL that has some missed pieces - for example, in LLDB we emulate to_string in such way: |
lib/Bitcode/Reader/BitcodeReader.cpp | ||
---|---|---|
3122 | OK I didn't know about the custom STL (I knew that it used a custom libc).
jroelofs: thanks for the suggestion, I didn't know Twine can do the to_string conversion implicitly. (and thanks ovyalov to have already implemented it). |
lib/Bitcode/Writer/BitcodeWriter.cpp | ||
---|---|---|
2848 | The revision that was actually submitted is different at least in this location: https://github.com/llvm-mirror/llvm/commit/b738d340fa9958dbefe8d23a4d4659c2255b823a The submitted version has a bug and a resulting memory leak. |
lib/Bitcode/Writer/BitcodeWriter.cpp | ||
---|---|---|
2848 | Fixed in r252110. The committed diff was significantly different because this last diff was a proposal for another scheme for the versioning (Major/Minor/Patch instead of Epoch), the committed diff is based on the previous diff for this revision. |
Stale comment?
Also "Can be used to provide better error messages when we fail to parse a bitcode file." maybe?