Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Upcoming changes around -Zembed-bitcode #9

Closed
alexcrichton opened this issue Apr 29, 2020 · 3 comments
Closed

Upcoming changes around -Zembed-bitcode #9

alexcrichton opened this issue Apr 29, 2020 · 3 comments

Comments

@alexcrichton
Copy link

Hello! I found this through an article today, and wanted to give y'all a heads up at some possible changes which may make things easier for y'all here.

rust-lang/rust#71528 is an effort to move all of rustc's storage of LLVM bitcode into object files by default instead of having some extra *.bc.z files in rlibs. Once that lands we'll be stabilizing -Cembed-bitcode as well so you won't have to use a -Z flag.

Some other notes that I saw while reading some scripts here:

  • If y'all are up for it the patch you have would likely be welcome upstream. We'd probably need to add a new target spec field so it's ios-specific, but that wouldn't be too too hard!
  • If you'd like I'd be happen to turn -fembed-bitcode on by default in cc so you don't have to specify an extra env var
  • I think it'd be fine to embed bitcode by default on all the ios targets (I believe there's an existing custom target spec option for this), which would remove the need for this extra configuration.
@thombles
Copy link
Member

thombles commented May 3, 2020

Hi, thanks for the welcome news! It will be great not to require -Z.

I'd thought about upstreaming that patch but I wasn't sure whether it would be desirable or where it would fit in, but you've just answered both those questions for me! I'll look into it.

I agree embedding bitcode is a sensible default for any iOS target, in cc or otherwise. I haven't spotted an obvious setting in the target spec fields but I might not be looking in the right place.

@alexcrichton
Copy link
Author

Oh I thought that this was actually already implemented but it appears I was wrong! I think what you'll want to do is:

  • Add some new fields to this structure
    • one would be "target forces embed bitcode"
    • another would be "default value of .llvmcmd"
  • The value of llvmcmd is threaded through to this location
  • Embedding bitcode is threaded through to here where it reads the value from the target spec. (if it's forced then the CLI value would be ignored most likely)
  • You'd then update these target spec values for the ios targets that need it.

@thombles thombles mentioned this issue May 7, 2020
Merged
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue May 8, 2020
@Dylan-DPC
Rollup merge of rust-lang#71970 - thombles:ios-bitcode-improvements, …
e3a4ff0 
…r=alexcrichton

Improve bitcode generation for Apple platforms

Some improvements for iOS bitcode support suggested by Alex over at getditto/rust-bitcode#9. r? @alexcrichton

This improves Rust's bitcode generation so that provided you have a compatible LLVM version, Rust targeting iOS should work out of the box when compiled into bitcode-enabled apps, and when submitted to the App Store. I've tested these changes using Xcode 11.4.1 and Apple's vendored LLVM, [tag `swift-5.2.3-RELEASE`](https://github.com/apple/llvm-project/releases/tag/swift-5.2.3-RELEASE).

1. Force `aarch64-apple-ios` and `aarch64-apple-tvos` targets to always emit full bitcode sections, even when cargo is trying to optimise by invoking `rustc` with `-Cembed-bitcode=no`. Since Apple recommends bitcode on iOS and requires it on tvOS it is likely that this is what developers intend. Currently you need to override the codegen options with `RUSTFLAGS`, which is far from obvious.
2. Provide an LLVM cmdline in the target spec. Apple's bitcode verification process looks for some arguments. For Rust modules to be accepted we must pretend they were produced similarly. A suitable default is provided in `TargetOptions` for iOS, copied directly from the a clang equivalent section.

In the context of Apple platforms, the predominant purpose of bitcode is App Store submissions, so simulator and 32-bit targets are not relevant. I'm hoping that the cmdline strings will not be a maintenance burden to keep up-to-date. If the event of any future incompatibilities, hopefully a custom target config would offer enough flexibility to work around it. It's impossible to say for sure.

Due to unrelated build errors I haven't been able to build and test a full tvOS toolchain. I've stopped short of providing a similar `bitcode_llvm_cmdline` until I can actually test it.
@thombles
Copy link
Member

thombles commented May 9, 2020

Building on the work mentioned in OP, the cmdline patch is now upstreamed along with a tweak that means aarch64-apple-ios will always embed bitcode without needing to use any -Z or -C flags: rust-lang/rust#71970

Presumably these improvements will land in 1.44.0, after which this repo will have less work to do and we can simplify things a bit. 🎉

For Ditto's purposes we'll most likely drop back to the stable channel. If there's anyone relying on the binaries who wants the nightly channel we could keep publishing those also.

@thombles thombles closed this as completed May 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@alexcrichton @thombles