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

Emscripten support take 2 (with bonus i686-unknown-linux-musl). #30629

Merged
merged 4 commits into from
Feb 6, 2016

Conversation

brson
Copy link
Contributor

@brson brson commented Dec 30, 2015

Here's another go at adding emscripten support. This needs to wait again on new libc definitions landing. To get the libc definitions right I had to add support for i686-unknown-linux-musl, which are very similar to emscripten's, which are derived from arm/musl.

This branch additionally removes the makefile dependency on the EMSCRIPTEN environment variable by not building the unused compiler-rt.

Again, this is not sufficient for actually compiling to asmjs since it needs additional LLVM patches.

r? @alexcrichton

llvm::LLVMWriteBitcodeToFile(llmod, out.as_ptr());
// Change what we write and cleanup based on whether obj files are
// just llvm bitcode. In that case write bitcode, and possibly
// delete the bitcode if it wasn't requisted. Don't generate the
Copy link
Member

Choose a reason for hiding this comment

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

requested (sorry about the nit, my eyes just fell on it)

@alexcrichton
Copy link
Member

r=me with one minor nit, but otherwise this'll just need libc to land first as well

@bors
Copy link
Contributor

bors commented Jan 13, 2016

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

@brson
Copy link
Contributor Author

brson commented Feb 6, 2016

Rebasing this now.

@brson brson force-pushed the emscripten-upstream branch 2 times, most recently from e1ced26 to b9dd828 Compare February 6, 2016 04:31
@brson
Copy link
Contributor Author

brson commented Feb 6, 2016

Well, I've rebased and addressed comments, and this builds, but testing against emscripten incoming it no longer produces working js.

Still, I'm up for landing this for the wip.

@brson
Copy link
Contributor Author

brson commented Feb 6, 2016

@bors r=alexcrichton

@bors
Copy link
Contributor

bors commented Feb 6, 2016

📌 Commit b9dd828 has been approved by alexcrichton

@brson
Copy link
Contributor Author

brson commented Feb 6, 2016

@bors r- I've got a commit that changes jemalloc in there.

@brson
Copy link
Contributor Author

brson commented Feb 6, 2016

@brson
Copy link
Contributor Author

brson commented Feb 6, 2016

@bors r=alexcrichton

@bors
Copy link
Contributor

bors commented Feb 6, 2016

📌 Commit 7afb56f has been approved by alexcrichton

Backtraces, and the compilation of libbacktrace for asmjs, are disabled.

This port doesn't use jemalloc so, like pnacl, it disables jemalloc *for all targets*
in the configure file.

It disables stack protection.
This tells trans::back::write not to LLVM codegen to create .o
files but to put LLMV bitcode in .o files.

Emscripten's emcc supports .o in this format, and this is,
I think, slightly easier than making rlibs work without .o
files.
@bors
Copy link
Contributor

bors commented Feb 6, 2016

⌛ Testing commit 7afb56f with merge 8c604dc...

bors added a commit that referenced this pull request Feb 6, 2016
Here's another go at adding emscripten support. This needs to wait again on new [libc definitions](rust-lang/libc#122) landing. To get the libc definitions right I had to add support for i686-unknown-linux-musl, which are very similar to emscripten's, which are derived from arm/musl.

This branch additionally removes the makefile dependency on the `EMSCRIPTEN` environment variable by not building the unused compiler-rt.

Again, this is not sufficient for actually compiling to asmjs since it needs additional LLVM patches.

r? @alexcrichton
@tamird
Copy link
Contributor

tamird commented May 1, 2016

@brson @alexcrichton a bit late to this party, but base.pre_link_args.push("-Wl,-melf_i386".to_string()); is the only bit of this that isn't shared with the 64-bit version and it isn't clear why. Can you shed some light on this difference?

@alexcrichton
Copy link
Member

AFAIK that's just to tell the linker to emit a 32-bit executable in case it's default a 64-bit one

@tamird
Copy link
Contributor

tamird commented May 3, 2016

Does that make it redundant with -m32?

On Mon, May 2, 2016 at 1:10 AM, Alex Crichton [email protected]
wrote:

AFAIK that's just to tell the linker to emit a 32-bit executable in case
it's default a 64-bit one


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#30629 (comment)

@alexcrichton
Copy link
Member

In this case, probably yes

@brson
Copy link
Contributor Author

brson commented May 3, 2016

@tamird Memory is hazy, but if I didn't write that it didn't work, and I don't know if it's redundant with -m32.

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

Successfully merging this pull request may close these issues.

5 participants