Better watch out! D runs on watchOS!

[Joakim via Digitalmars-d-announce]

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