Bitcode and OpenSSL

We're working on supporting Bitcode in PSPDFKit but hit a blocking issue with OpenSSL (latest 1.0.2d).


We're using a script that downloads and builds OpenSSL into fat static libraries for both Mac and iOS. I've put the gist here:

https://gist.github.com/steipete/ce09ba176a4b8ef66b2d/bf053eab1c0f8494dcd3748079543c4ed4367b9c


Enabling Bitcode should be as easy as adding `-fembed-bitcode` as clang flag according to this entry. That's exactly what I did.


Now things build, but the script eventually stops with this error:

ld: could not open bitcode temp file: ../libcrypto.a(aes-x86_64.o) for architecture x86_64


Full log here: https://gist.github.com/steipete/8daebf333263c98ec752

Now I assume this is because aes-x86_64.o is compiled from aes-x86_64.s which is assembly - so there can't be any bitcode generated for it.

According to this forum entry this shouldn't be a problem.

Things also compile well for the armv7 and arm64 part:

https://gist.github.com/steipete/539c924ad939ca8e3f36

I assume this is because there, aes.c can be compiled to bitcode (there's no specialized assembly for armv7/arm64)

Here's a list of the specialized code paths for aes:

https://github.com/luvit/openssl/tree/master/openssl/crypto/aes/asm


I've verified with `otool -l lib.o | grep bitcode` that the armv7/64 parts indeed contains bitcode. (Emiting lots of sectname __bitcode entries)


Now here's my question. What am I doing wrong? Is this a bug, can we only build libraries with bitcode when there is no assembly used?

Or do we need to customize the script to not pass `-fembed-bitcode` when compiling assembly?


Update: While writing this, I investigated more and found that when we add the `no-asm` flag to the x86_64 architecture, it does work.

Yet, this obviously degrates performance, so I'd love to have a second opinion from someone from the LLVM/Clang team.


tl;dr If you don't care about performance and want OpenSSL with Bitcode, use this script and maybe say thanks on Twitter; @steipete here.

https://gist.github.com/steipete/ce09ba176a4b8ef66b2d

Replies

It seems to be a bug in ld tool while checking at assembly object files. It is treating ARM assembly .o files included in static libs as external files. If you create a zero byte file with the file name "libcrypto.a(aes-x86_64.o)" in the same folder of your .a file, it will work.

Can someone from the compiler team comment on the safety of this? I personally have no other choice for now than disabling OpenSSL in my entire project because I can't trust Bitcode to not optimize away time-safety operations in cryptographic libraries.


It would be really insightful to get ANY information about the types of optimizations that will be performed between the code I upload and the one that is distributed. Keep in mind that due to the FairPlay DRM, as a developer, we can't easily read the assembly code of our applications without jailbreaking. That's really a bummer.

Hi,


I suggest not to remove OpenSSL, but to disable Bitcode completely until bug will be resolved