rustc: Enable embedding LLVM bitcode for iOS by alexcrichton · Pull Request #48896 · rust-lang/rust

alexcrichton · 2018-03-09T22:12:39Z

This commit updates rustc to embed bitcode in each object file generated by
default when compiling for iOS. This was determined in #35968 as a step
towards better compatibility with the iOS toolchain, so let's give it a spin and
see how it turns out!

Note that this also updates the cc dependency which should propagate this
change of embedding bitcode for C dependencies as well.

rust-highfive · 2018-03-09T22:12:50Z

r? @michaelwoerister

(rust_highfive has picked a reviewer for you, use r? to override)

alexcrichton · 2018-03-09T22:13:19Z

cc @comex, @michaeleiselsc, y'all may want to double check me on this!

alexcrichton · 2018-03-09T22:15:21Z

Some helpful links thanks to @comex

https://github.com/llvm-mirror/clang/blob/b641d31365414ba3ea0305fdaa80369a9efb6bd9/lib/CodeGen/BackendUtil.cpp#L1242 - LLVM's support for this
https://opensource.apple.com/source/ld64/ld64-274.2/src/ld/parsers/macho_relocatable_file.cpp.auto.html - the linker source where these sections are loaded

michaeleiselsc · 2018-03-09T22:17:52Z

i'm still not sure if we want to always have bitcode on, i think it may cause binary bloat for internal distributions, @comex do you know?

comex · 2018-03-10T00:19:34Z

Well, I don't know of anything that would normally strip it out. (In particular, strip doesn't remove bitcode, which makes sense because Xcode runs strip by default when building the archive you'd send to Apple.) I don't know whether any third-party app distribution platforms (for betas or internal corporate apps) have custom tooling to strip it out. I also don't know how much bitcode typically adds to binary sizes. So… no idea :)

I'm building this PR locally and will at least do a basic test of whether I can build a Rust static library and link it into an iOS app with bitcode enabled, without the linker complaining about missing bitcode objects. That wouldn't guarantee that the bitcode is actually reasonable: in particular, rustc currently defaults to building against LLVM 6, while the latest Xcode is based on LLVM 5, and I have no idea what Apple's servers are running. But it's a start.

michaeleiselsc · 2018-03-10T00:38:45Z

a few more questions:

what happens when the linker receives a mix of bitcode files and non-bitcode files, e.g. because a project doesn't want to use bitcode but is built with a mix of rust and other languages where bitcode is turned off?
does the app store assume that bitcode in the executable means that it should use the bitcode for its distribution process, or is there another toggle the user has to use? if it's the former, then we would be forcing people to use the app store bitcode process

alexcrichton · 2018-03-10T03:04:57Z

@comex thanks for testing!

@michaeleiselsc I'm not so sure myself, I'm relying on y'all for guidance on what you need from rustc :(

comex · 2018-03-10T09:07:31Z

I tried to test it but ran into some issues with the standard library build - in particular, #48906, which I just filed, combined with an odd bug where nm (and maybe other things?) rejects object files that were compiled with -fembed-bitcode-marker. I'll look further tomorrow.

michaeleiselsc · 2018-03-11T08:54:38Z

It feels like there are a lot of potential issues with always generating bitcode, so although I can take a look at them, I feel like we should provide an option not to emit bitcode. In fact, because bitcode in Xcode is off by default IIRC, perhaps we should make the default be not to generate bitcode and just provide this as an option

bors · 2018-03-11T23:08:49Z

☔ The latest upstream changes (presumably #48549) made this pull request unmergeable. Please resolve the merge conflicts.

comex · 2018-03-12T04:46:11Z

Okay, I figured out what's going on.

LLVM's code for reading object files has a bug that causes it to mishandle -fembed-bitcode-marker objects. It's a pretty obvious bug - e.g. you get an error if you run nm on such objects - but I guess nobody noticed because -fembed-bitcode-marker has only been used by Xcode in limited circumstances. I submitted a patch to LLVM upstream. (This does not affect objects with actual embedded bitcode, i.e. -fembed-bitcode without -marker.)
rustc's bootstrap has a bug (filed as bootstrap should set optimization level when calculating cflags #48906) that causes it to build libbacktrace (among other things) with -fembed-bitcode-marker even when optimization is on. Not to be confused with an entirely separate bug I discovered during the process, libbacktrace is always built without optimization #48903, with a different cause, that causes libbacktrace to actually be built without optimization (on all platforms!) :)
The aforementioned LLVM bug causes rustc to produce broken static libraries: specifically, the index (as shown by nm --print-armap) is missing all symbols from objects compiled with -fembed-bitcode-marker. If you extract the object files from the archive, the symbols are there, but they're not indexed. (As far as I can tell, this issue doesn't affect libraries created with ar, which makes sense since Apple still ships ar from cctools rather than symlinking it to llvm-ar. But rustc produces static libraries directly using LLVM, without using ar.)
So on my test setup, which has rustc make a static library for Xcode to link to, ld complains about undefined symbols for _backtrace_create_state, _backtrace_syminfo, _backtrace_pcinfo. (This is the exact same error @michaeleiselsc encountered in this post, but in his case there was an entirely different cause: he was using --emit=llvm-bc, so libbacktrace wasn't being included at all.)
As a hack, if I run ranlib on the library before linking (which should not be necessary), my test setup works! (Well, it works for test builds, which are linked using -fembed-bitcode-marker. If I try an archive build, it naturally complains because libbacktrace doesn't actually have bitcode embedded, i.e. bootstrap should set optimization level when calculating cflags #48906.)

For now, as a workaround for the LLVM bug, I think the best approach is to avoid -fembed-bitcode-marker or equivalent, in both this PR and cc-rs. Either embed bitcode by default even for debug builds, or just disable entirely by default for now. Once the LLVM bug has been fixed and the fix is shipping in Xcode, the default can be changed back.

Also, I agree with @michaeleiselsc that there should be an option to control the behavior.

michaeleiselsc · 2018-03-12T19:08:43Z

@comex does this relate to the dsymutil segfault I was getting? It seems that rustc does not always generate good symbols (#46447), so perhaps this is triggering that

alexcrichton · 2018-03-12T20:38:31Z

Thanks for the investigation @comex! I've updated to fix those various rustbuild issues you pointed out and went ahead and disabled this by default for iOS. It can be enabled with -Z embed-bitcode

michaelwoerister · 2018-03-13T10:11:29Z

Ping me when this is ready for review.

* Pass `opt_level(2)` when calculating CFLAGS to get the right flags on iOS * Unconditionally pass `-O2` when compiling libbacktrace This should... Closerust-lang#48903Closerust-lang#48906

This commit updates rustc to embed bitcode in each object file generated by default when compiling for iOS. This was determined in rust-lang#35968 as a step towards better compatibility with the iOS toolchain, so let's give it a spin and see how it turns out! Note that this also updates the `cc` dependency which should propagate this change of embedding bitcode for C dependencies as well.

alexcrichton · 2018-03-13T15:30:15Z

Ok @michaelwoerister I think this should be ready!

@michaeleiselsc errors like #46447may have been fixed by #46772, although maybe not as well

michaelwoerister · 2018-03-13T17:16:29Z

+ ".llvmbc\0"
+ };
+ llvm::LLVMSetSection(llglobal, section.as_ptr() as *const _);
+ llvm::LLVMRustSetLinkage(llglobal, llvm::Linkage::PrivateLinkage);


I guess this is what clang is doing?

michaelwoerister · 2018-03-13T17:17:20Z


 fn build_libbacktrace(host: &str, target: &str) -> Result<(), ()> {
 let native = native_lib_boilerplate("libbacktrace", "libbacktrace", "backtrace", ".libs")?;
+ let cflags = env::var("CFLAGS").unwrap_or_default() + " -fvisibility=hidden -O2";


Is this related to bitcode embedding?

Sort of tangentially yeah, but it's otherwise fixing issues that @comex brought up when testing this

I later saw that this is in a separate commit with proper commit message anyway. Thanks for the info!

michaelwoerister · 2018-03-13T17:18:41Z

Thanks, @alexcrichton! Looks good to me.

@bors r+

bors · 2018-03-13T17:18:42Z

📌 Commit 0e0f74b has been approved by michaelwoerister

bors · 2018-03-16T13:48:27Z

⌛ Testing commit 0e0f74b with merge 3b6412b...

…ster rustc: Enable embedding LLVM bitcode for iOS This commit updates rustc to embed bitcode in each object file generated by default when compiling for iOS. This was determined in #35968 as a step towards better compatibility with the iOS toolchain, so let's give it a spin and see how it turns out! Note that this also updates the `cc` dependency which should propagate this change of embedding bitcode for C dependencies as well.

bors · 2018-03-16T16:43:48Z

☀️ Test successful - status-appveyor, status-travis
Approved by: michaelwoerister
Pushing 3b6412b to master...

rust-highfive assigned michaelwoerister Mar 9, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 9, 2018

alexcrichton force-pushed the bitcode-in-object branch from db9d67e to d2855b0Compare March 9, 2018 23:09

alexcrichton force-pushed the bitcode-in-object branch from d2855b0 to b9120a9Compare March 12, 2018 20:37

alexcrichton force-pushed the bitcode-in-object branch from b9120a9 to d9f6aebCompare March 12, 2018 20:46

rustbuild: Tweak CFLAGS to various libstd pieces
1999a3f
* Pass `opt_level(2)` when calculating CFLAGS to get the right flags on iOS * Unconditionally pass `-O2` when compiling libbacktrace This should... Closerust-lang#48903Closerust-lang#48906

alexcrichton force-pushed the bitcode-in-object branch from d9f6aeb to b284fbaCompare March 13, 2018 15:28

alexcrichton force-pushed the bitcode-in-object branch from b284fba to 0e0f74bCompare March 13, 2018 15:29

michaelwoerister reviewed Mar 13, 2018
View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 13, 2018

markuscraig mentioned this pull request Mar 14, 2018
Custom LLVM options for iOS Bitcode Framework? JetBrains/kotlin-native#1408
Closed

alexcrichton changed the title ~~rustc: Embed LLVM bitcode by default on iOS~~rustc: Enable embedding LLVM bitcode for iOSMar 15, 2018

comex mentioned this pull request Mar 15, 2018
Bitode fembed-bitcode-marker breaking iOS debug builds rust-lang/cc-rs#301
Closed

bors merged commit 0e0f74b into rust-lang:masterMar 16, 2018

alexcrichton deleted the bitcode-in-object branch March 19, 2018 17:52

chrisballinger mentioned this pull request Apr 27, 2018
Support Apple app store bitcode #35968
Closed

alastaircoote mentioned this pull request Apr 30, 2018
Bitcode support for iOS frameworks JetBrains/kotlin-native#1202
Closed

Uh oh!

Uh oh!

Conversation

alexcrichton commented Mar 9, 2018

Uh oh!

rust-highfive commented Mar 9, 2018

Uh oh!

alexcrichton commented Mar 9, 2018

Uh oh!

alexcrichton commented Mar 9, 2018

Uh oh!

michaeleiselsc commented Mar 9, 2018

Uh oh!

comex commented Mar 10, 2018

Uh oh!

michaeleiselsc commented Mar 10, 2018

Uh oh!

alexcrichton commented Mar 10, 2018

Uh oh!

comex commented Mar 10, 2018

Uh oh!

michaeleiselsc commented Mar 11, 2018

Uh oh!

bors commented Mar 11, 2018

Uh oh!

comex commented Mar 12, 2018• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

michaeleiselsc commented Mar 12, 2018

Uh oh!

alexcrichton commented Mar 12, 2018

Uh oh!

michaelwoerister commented Mar 13, 2018

Uh oh!

alexcrichton commented Mar 13, 2018

Uh oh!

michaelwoeristerMar 13, 2018

Choose a reason for hiding this comment

Uh oh!

michaelwoeristerMar 13, 2018

Choose a reason for hiding this comment

Uh oh!

alexcrichtonMar 13, 2018

Choose a reason for hiding this comment

Uh oh!

michaelwoeristerMar 14, 2018

Choose a reason for hiding this comment

Uh oh!

michaelwoerister commented Mar 13, 2018

Uh oh!

bors commented Mar 13, 2018

Uh oh!

bors commented Mar 16, 2018

Uh oh!

bors commented Mar 16, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

comex commented Mar 12, 2018•
edited
Loading