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.

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

Working asmjs and wasm targets #36339

Merged
merged 27 commits into from
Oct 1, 2016
Merged

Working asmjs and wasm targets #36339

merged 27 commits into from
Oct 1, 2016

Conversation

brson
Copy link
Contributor

@brson brson commented Sep 8, 2016

This patch set results in a working standard library for the asmjs-unknown-emscripten and wasm32-unknown-emscripten targets. It is based on the work of @badboy and @rschulman.

It does a few things:

  • Updates LLVM with the emscripten fastcomp patches, which include the pnacl IR legalizer and the asm.js backend. This patch is thought not to have any significant effect on existing targets.
  • Teaches rustbuild to correctly link C code with emscripten
  • Updates gcc-rs to work correctly with emscripten
  • Teaches rustbuild to run crate tests for emscripten with node
  • Modifies Thread::new to return an error on emscripten, to facilitate debugging a common failure mode
  • Modifies libtest to run in single-threaded mode for emscripten
  • Ignores a host of tests that don't work yet, mostly dealing with threads and I/O
  • Updates libc with wasm32 definitions (presently the same as asmjs)
  • Adds a wasm32-unknown-emscripten target that feeds the output of LLVM's asmjs backend through emcc to generate wasm

Notes and caveats:

  • This is only known to work with --enable-rustbuild.
  • The wasm32 target can't be tested correctly yet because of issues in compiletest and limitations in node Running wasm output via node does not work when in a different directory emscripten-core/emscripten#4542, but hello.rs does seem to work when run on node via the binaryen interpreter
  • This requires an up to date installation of the emscripten sdk from its incoming branch
  • Unwinding is very broken
  • When enabling the emscripten targets jemalloc is disabled for all targets, which results in test failures for the host

Next steps are to fix the jemalloc issue, start building the two emscripten targets on the auto builders, then start producing nightlies.

#36317 tracks work on this.

Fixes #36515
Fixes #36515
Fixes #36356

@rust-highfive
Copy link
Collaborator

r? @alexcrichton

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

@brson
Copy link
Contributor Author

brson commented Sep 8, 2016

I have lingering doubts about the modification to Thread::new: why just this function and not others, why an error instead of panic.

@brson
Copy link
Contributor Author

brson commented Sep 8, 2016

One thing to note about this patch is that debugging crate test failures is quite difficult because many failures result in aborts, not clean test failures. Often this is because of fatal errors in emscripten for various reasons; perhaps some because of the utterly broken unwinding support.

@tomaka
Copy link
Contributor

tomaka commented Sep 8, 2016

In my opinion we should pass -s ERROR_ON_UNDEFINED_SYMBOLS=1 to emscripten. By default linker error generate an abort at runtime instead of compile-time. See this comment.

Other than that, there's the question of DISABLE_EXCEPTION_CATCHING. See this page.
Since Rust gives the possibility to set panic=abort, I think that this flag should be set to 0 when the panic strategy is unwind and to 1 when it is abort.

.. Default::default()
};
Ok(Target {
llvm_target: "asmjs-unknown-emscripten".to_string(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be wasm32-unknown-emscripten?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh wait nevermind, this isn't using the wasm backend of LLVM.

@alexcrichton
Copy link
Member

I've realized one further issue where we may not need to actually include the fastcomp backend, but I would prefer to land this ahead of that and we can decide on it later.

@bors
Copy link
Contributor

bors commented Sep 11, 2016

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

@alexcrichton
Copy link
Member

This may also want to use the support added in #36256 to figure out which node to run rather than always using "node"

@brson
Copy link
Contributor Author

brson commented Sep 14, 2016

I've got a patch to make the test changes, remove the Thread::spawn error handling, and fix libtest. Testing it now.

Still have to investigate the jemalloc problems, though this can land without fixes for that. Still have to rebase to incorporate #36256.

@tomaka
Copy link
Contributor

tomaka commented Sep 14, 2016

Please don't forget my remark. You may have linking errors and not realize it.

@brson
Copy link
Contributor Author

brson commented Sep 15, 2016

@tomaka Thanks for the reminder. I will definitely add the ERROR_ON_UNDEFINED_SYMBOLS=1 flag. The unwinding stuff for future work.

@brson brson force-pushed the emscripten-new branch 2 times, most recently from 2ea0371 to 80a1288 Compare September 16, 2016 01:01
@brson
Copy link
Contributor Author

brson commented Sep 16, 2016

@tomaka I looked into adding the flag and it looks impractical to do in this PR because every test case encounters undefined symbols related to the unwinder. I did file a bug #36515

@brson
Copy link
Contributor Author

brson commented Sep 16, 2016

@alexcrichton I think this is ready to go but still running tests.

Doing this step for the target results in the build system
trying to build rustc for asmjs, which doesn't work.
This is a hack to support building targets that don't support jemalloc
alongside hosts that do. The jemalloc build is controlled by a feature
of the std crate, and if that feature changes between targets, it
invalidates the fingerprint of std's build script (this is a cargo
bug); so we must ensure that the feature set used by std is the same
across all targets, which means we have to build the alloc_jemalloc
crate for targets like emscripten, even if we don't use it.
@brson
Copy link
Contributor Author

brson commented Sep 30, 2016

I've confirmed this build works with the smaller LLVM patch.

@brson
Copy link
Contributor Author

brson commented Sep 30, 2016

@bors r=alexcrichton

@bors
Copy link
Contributor

bors commented Sep 30, 2016

📌 Commit afa72b5 has been approved by alexcrichton

@bors
Copy link
Contributor

bors commented Oct 1, 2016

⌛ Testing commit afa72b5 with merge 8b00355...

bors added a commit that referenced this pull request Oct 1, 2016
Working asmjs and wasm targets

This patch set results in a working standard library for the asmjs-unknown-emscripten and wasm32-unknown-emscripten targets. It is based on the work of @badboy and @rschulman.

It does a few things:

- Updates LLVM with the emscripten [fastcomp](rust-lang/llvm#50) patches, which include the pnacl IR legalizer and the asm.js backend. This patch is thought not to have any significant effect on existing targets.
- Teaches rustbuild to correctly link C code with emscripten
- Updates gcc-rs to work correctly with emscripten
- Teaches rustbuild to run crate tests for emscripten with node
- Modifies Thread::new to return an error on emscripten, to facilitate debugging a common failure mode
- Modifies libtest to run in single-threaded mode for emscripten
- Ignores a host of tests that don't work yet, mostly dealing with threads and I/O
- Updates libc with wasm32 definitions (presently the same as asmjs)
- Adds a wasm32-unknown-emscripten target that feeds the output of LLVM's asmjs backend through emcc to generate wasm

Notes and caveats:

- This is only known to work with `--enable-rustbuild`.
- The wasm32 target can't be tested correctly yet because of issues in compiletest and limitations in node emscripten-core/emscripten#4542, but hello.rs does seem to work when run on node via the binaryen interpreter
- This requires an up to date installation of the emscripten sdk from its incoming branch
- Unwinding is very broken
- When enabling the emscripten targets jemalloc is disabled for all targets, which results in test failures for the host

Next steps are to fix the jemalloc issue, start building the two emscripten targets on the auto builders, then start producing nightlies.

#36317 tracks work on this.

Fixes #36515
Fixes #36515
Fixes #36356
@bors
Copy link
Contributor

bors commented Oct 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
7 participants