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
