4 ms·

I only skimmed, but I found several mistakes. With bitcode, you still get one bitcode slice per arch since LLVM bitcode isn't platform-independent. Pointers are

by bla2 8y ago

I only skimmed, but I found several mistakes. With bitcode, you still get one bitcode slice per arch since LLVM bitcode isn't platform-independent. Pointers are for example sized differently, which causes the same C file to compile to different bitcode; preprocessor macros are different, which also causes the same C file to compile to different bitcode; and so on. App thinning can be implemented without bitcode, so that whole "What problems Apple’s Bitcode aims to solve?" section is bogus.

bla2 8y ago
The "What problems do Bitcode introduce?" section is a bit silly too: Production binaries you ship don't contain bitcode. For store apps, the app store will strip it, for non-store apps you strip it yourself. It's like shipping your app with debug info, that also makes reversing easier. Finally, the bitcode_retriever code is fine, but you could get the same functionality with 3 lines of shell (`otool -l mybinary | grep -A 4 __bitcode` to get the part of the file containing bitcode and then use `dd` to extract that).
0x0 8y ago
Agreed, my impression is that the main benefit of bitcode is that it allows Apple to rebuild apps for the purposes of fixing compiler backend bugs and perhaps introducing improved micro-optimizations for newer CPUs generations within the same architecture, but it certainly does not work as a "java bytecode" layer - it definitively wouldn't enable Apple to change to a completely different CPU architecture in newer iPhones or Macs. The LLVM IR and the ObjectiveC/Swift/libc ABI is too architecture-specific to work as a portability layer.
- glhaynes 8y ago
  my impression is that the main benefit of bitcode is that it allows Apple to rebuild apps for the purposes of fixing compiler backend bugs and perhaps introducing improved micro-optimizations for newer CPUs generations within the same architecture This is my impression, too, but it's always seemed strange to me - are the rare fix for a compiler bug and a few micro-optimizations worth all the effort?
  - 0x0 8y ago
    Maybe they expected more compiler bugs than usual when bringing out Swift?

by bla2 8y ago

bla2 8y ago

The "What problems do Bitcode introduce?" section is a bit silly too: Production binaries you ship don't contain bitcode. For store apps, the app store will strip it, for non-store apps you strip it yourself. It's like shipping your app with debug info, that also makes reversing easier. Finally, the bitcode_retriever code is fine, but you could get the same functionality with 3 lines of shell (`otool -l mybinary | grep -A 4 __bitcode` to get the part of the file containing bitcode and then use `dd` to extract that).

0x0 8y ago

Agreed, my impression is that the main benefit of bitcode is that it allows Apple to rebuild apps for the purposes of fixing compiler backend bugs and perhaps introducing improved micro-optimizations for newer CPUs generations within the same architecture, but it certainly does not work as a "java bytecode" layer - it definitively wouldn't enable Apple to change to a completely different CPU architecture in newer iPhones or Macs. The LLVM IR and the ObjectiveC/Swift/libc ABI is too architecture-specific to work as a portability layer.

glhaynes 8y ago
my impression is that the main benefit of bitcode is that it allows Apple to rebuild apps for the purposes of fixing compiler backend bugs and perhaps introducing improved micro-optimizations for newer CPUs generations within the same architecture This is my impression, too, but it's always seemed strange to me - are the rare fix for a compiler bug and a few micro-optimizations worth all the effort?
- 0x0 8y ago
  Maybe they expected more compiler bugs than usual when bringing out Swift?