On Monday, 28 December 2015 at 08:45:46 UTC, Dan Olson wrote:
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.

Thanks for the detailed answer; I'm sure this will now become the definitive answer online. I've gone googling for technical info only to sometimes be directed back to a post in these D forums. :)

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.

Time to get emulated TLS for Mach-O into llvm, as one google engineer did with ELF for Android, which will be released in the upcoming llvm 3.8:

https://code.google.com/p/android/issues/detail?id=78122

Reply via email to