Joakim <dl...@joakim.fea.st> writes: > > I don't understand how the bitcode requirement works on your own > device: I thought that was for an Apple-submitted app that they then > compiled to binary themselves? Do you have to go through the same > process even for test apps, ie no sideloading? Or does the device > itself take bitcode?
This is all based on my experience and I don't know the full bitcode story. I may state erroneous info below. The device takes normal executables but there is a check to make sure that each object file has the appropriate bitcode sections. I think the linker does this, but did not check which tool in build chain spit out the error. The bitcode is actually two new sections in every object file: .section __LLVM,__bitcode .section __LLVM,__cmdline The __bitcode section seems to just be the LLVM IR for the object file in the .bc binary format. Some sources say it is a xar archive but in my investigation I used Apple's clang with -fembed-bitcode and inspected the IR or ARM assembly to see these two sections. Extracting and using llvm-dis on the __bitcode section gave back the containing module's IR in human readable format. It exactly matches the LLVM IR for its object file sans Apple's clang -fembed-bitcode. So not sure when xar is used yet. The __cmdline section appears to be some of the clang options used to compile the bitcode. The compile process becomes something like this: 1. Create IR for module as usual. 2. Generate the IR bitcode representation. 3. Add the two new sections, using bitcode from (2) as contents of __bitcode section and __cmdline options to compile it 4. Generate object from IR. But not wanting to figure all that out now, I tried simpler things and discovered that at least for testing, these sections only need to be present and the contents don't seem to matter. So for now I skip 2 and just put a zero in each. On implication of Apple requiring bitcode: if Apple is compiling the bitcode with their clang or llc, then it means using a modifed LLVM like I do to support thread-locals on watchOS, tvOS, or iOS is only good for side loading. Probably going to have to work on plan B for thread-locals. -- Dan