[cfe-dev] [LLVMdev] Proposal to add Bitcode version field to bitcode file wrapper

[David Blaikie]

On Sat, Sep 27, 2014 at 11:35 PM, Alex Rosenberg <alexr at leftfield.org>
wrote:

> How is this use case different from the LTO-supported toolchains shipped
> by other vendors such as Apple? Do they have this theoretical problem too?
>
> If the issue is solely constrained to debug info metadata, then why not
> use metadata to describe the format/version of the debug info?
>

FWIW (I haven't followed the rest of this thread) - that's what we/Apple
have done. There's a module flag metadata that specifies the debug info
metadata schema version, then the verifier (or some other pass, I forget
how it's phrased) can check if the version matches the current LLVM's debug
info metadata version, and if it doesn't match, it strips out all the debug
info metadata.


>
> Alex
>
> On Sep 27, 2014, at 3:19 AM, Greg Bedwell <gregbedwell at gmail.com> wrote:
>
> As I understand it, the bitcode compatibility promise doesn't extend as
> far as debug info metadata (happy to be wrong here!).  I think we have a
> usecase where need to guarantee that debug information from any two
> arbitrary bitcode files going into an LTO link will result in the
> expected/correct debug information going into the resulting ELF file;
> unless we can be sure that this will always work between bitcode files
> generated by different versions we'd need some way of flagging up an
> incompatibility and providing useful information on the reason to the user.
>
> --Greg Bedwell
> SN Systems - Sony Computer Entertainment Group
>
> On 27 September 2014 02:24, Sean Silva <chisophugis at gmail.com> wrote:
>
>>
>>
>> On Fri, Sep 26, 2014 at 5:18 PM, Yung, Douglas <
>> douglas_yung at playstation.sony.com> wrote:
>>
>>>  Sorry if I was unclear. There are currently no “known
>>> incompatibilities” that I am aware of, although I fully admit to not being
>>> an expert on the topic. The idea is that we add versioning information to
>>> the bitcode so that if an issue were discovered, it could be easily
>>> detected and dealt with.
>>>
>>
>> It sounds like time would be better invested in improving the testing of
>> our bitcode compatibility promise.
>>
>> -- Sean Silva
>>
>>
>>>
>>>
>>> Douglas Yung
>>>
>>>
>>>
>>> *From:* Bob Wilson [mailto:bob.wilson at apple.com]
>>> *Sent:* Friday, September 26, 2014 16:39
>>> *To:* Yung, Douglas
>>> *Cc:* llvmdev at cs.uiuc.edu; cfe-dev at cs.uiuc.edu
>>> *Subject:* Re: [LLVMdev] Proposal to add Bitcode version field to
>>> bitcode file wrapper
>>>
>>>
>>>
>>> Bitcode backward compatibility, at least for the current major version,
>>> is supposed to make this unnecessary. Can you provide more information
>>> about what “known incompatibilities” you’re seeing?
>>>
>>>
>>>
>>>  On Sep 26, 2014, at 2:40 PM, Yung, Douglas <
>>> douglas_yung at playstation.sony.com> wrote:
>>>
>>>
>>>
>>> Hi,
>>>
>>>
>>>
>>> We would like to add a version number to the bitcode wrapper. This
>>> feature would allow easier identification of what compiler produced the
>>> bitcode so that known incompatibilities with LTO compilation could be
>>> detected. Roughly speaking, this version number would consist of the major,
>>> minor and optionally the patch version of the compiler used to produce the
>>> bitcode. The version information would be encoded in 4 bytes, with the
>>> first byte representing the major version number, the second byte the minor
>>> version number, and the third and fourth bytes optionally encoding the
>>> patch version or other information. As to where to place this information,
>>> we are considering two different possibilities for updating the bitcode
>>> wrapper specification.
>>>
>>>
>>>
>>> The first is to simply add a single 32bit wide field at the end of the
>>> existing bitcode wrapper format field. This would result in the new
>>> structure looking like this:
>>>
>>> [Magic_{32}, Version_{32}, Offset_{32}, Size_{32}, CPUType_{32},
>>> BitcodeVersion_{32}]
>>>
>>> All of the existing fields would keep their current meanings, and the
>>> new field BitcodeVersion is simply appended with the format described in
>>> the first paragraph.
>>>
>>> A second idea was to use the existing Version field in the bitcode
>>> wrapper format to store the bitcode version information. According to the
>>> documentation (
>>> http://llvm.org/docs/BitCodeFormat.html#bitcode-wrapper-format) this
>>> field is currently always set to 0. This would allow us to make use of what
>>> is (presumably) an unused field.
>>>
>>>
>>>
>>> As this is a feature that we feel would be beneficial to the community,
>>> we wanted to get feedback on the design for our upcoming patches. Any
>>> thoughts or opinions on this would be greatly appreciated.
>>>
>>>
>>>
>>> Thanks!
>>>
>>>
>>>
>>> Douglas Yung
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140928/ae516e10/attachment.html>