rust-lang/rust
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
b294cc71a2244fb11dad0b1b22e9f27d4b8fba47
rust/compiler/rustc_target/src/spec/wasm32_unknown_unknown.rs

43 lines
1.6 KiB
Rust
Raw Normal View History

rustc: Allow using `clang` for wasm32 targets This commit adds support code for using `clang` directly to link the wasm32-unknown-unknown target. Currently the target is only really configured to link with LLD directly, but this ensures that `clang` can be configured as well. While not immediately useful in the near term it's likely that more wasm32 targets will pop up over time with Clang's new native support for WebAssembly in the 8.0.0 release. Getting support into rustc early should make it easier to experiment with these targets and try out various changes here and there.
2019-03-19 13:06:37 -07:00
//! A "bare wasm" target representing a WebAssembly output that makes zero
//! assumptions about its environment.
//!
//! The `wasm32-unknown-unknown` target is intended to encapsulate use cases
//! that do not rely on any imported functionality. The binaries generated are
//! entirely self-contained by default when using the standard library. Although
//! the standard library is available, most of it returns an error immediately
//! (e.g. trying to create a TCP stream or something like that).
//!
//! This target is more or less managed by the Rust and WebAssembly Working
Fix automatic_links warnings
2020-10-14 17:35:43 +02:00
//! Group nowadays at <https://github.com/rustwasm>.
rustc: Allow using `clang` for wasm32 targets This commit adds support code for using `clang` directly to link the wasm32-unknown-unknown target. Currently the target is only really configured to link with LLD directly, but this ensures that `clang` can be configured as well. While not immediately useful in the near term it's likely that more wasm32 targets will pop up over time with Clang's new native support for WebAssembly in the 8.0.0 release. Getting support into rustc early should make it easier to experiment with these targets and try out various changes here and there.
2019-03-19 13:06:37 -07:00
use super::wasm32_base;
Format the world
2019-12-22 17:42:04 -05:00
use super::{LinkerFlavor, LldFlavor, Target};
std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a "custom linker" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed, rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error, but anything related to allocation works (aka `HashMap`, `Vec`, etc). * Naturally, any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The "linking" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target, so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's "production ready". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored, but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the "smallest possible wasm module" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final "bloat" in vanilla rustc (again, a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this, particularly on the various integration points if you've got better ideas of how to approach them!
2017-10-22 20:01:00 -07:00
rustc_target: Refactor away `TargetResult` Construction of a built-in target is always infallible now, so `TargetResult` is no longer necessary.
2020-10-05 15:37:55 +03:00
pub fn target() -> Target {
rustc: Allow using `clang` for wasm32 targets This commit adds support code for using `clang` directly to link the wasm32-unknown-unknown target. Currently the target is only really configured to link with LLD directly, but this ensures that `clang` can be configured as well. While not immediately useful in the near term it's likely that more wasm32 targets will pop up over time with Clang's new native support for WebAssembly in the 8.0.0 release. Getting support into rustc early should make it easier to experiment with these targets and try out various changes here and there.
2019-03-19 13:06:37 -07:00
let mut options = wasm32_base::options();
rustc_target: Move `target_os` from `Target` to `TargetOptions`
2020-10-08 20:54:45 +03:00
options.target_os = "unknown".to_string();
rustc: Allow using `clang` for wasm32 targets This commit adds support code for using `clang` directly to link the wasm32-unknown-unknown target. Currently the target is only really configured to link with LLD directly, but this ensures that `clang` can be configured as well. While not immediately useful in the near term it's likely that more wasm32 targets will pop up over time with Clang's new native support for WebAssembly in the 8.0.0 release. Getting support into rustc early should make it easier to experiment with these targets and try out various changes here and there.
2019-03-19 13:06:37 -07:00
let clang_args = options.pre_link_args.get_mut(&LinkerFlavor::Gcc).unwrap();
std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a "custom linker" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed, rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error, but anything related to allocation works (aka `HashMap`, `Vec`, etc). * Naturally, any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The "linking" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target, so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's "production ready". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored, but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the "smallest possible wasm module" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final "bloat" in vanilla rustc (again, a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this, particularly on the various integration points if you've got better ideas of how to approach them!
2017-10-22 20:01:00 -07:00
rustc: Allow using `clang` for wasm32 targets This commit adds support code for using `clang` directly to link the wasm32-unknown-unknown target. Currently the target is only really configured to link with LLD directly, but this ensures that `clang` can be configured as well. While not immediately useful in the near term it's likely that more wasm32 targets will pop up over time with Clang's new native support for WebAssembly in the 8.0.0 release. Getting support into rustc early should make it easier to experiment with these targets and try out various changes here and there.
2019-03-19 13:06:37 -07:00
// Make sure clang uses LLD as its linker and is configured appropriately
// otherwise
clang_args.push("--target=wasm32-unknown-unknown".to_string());
rustc: Add an option to default hidden visibility This commit adds a new option to target specifictions to specify that symbols should be "hidden" visibility by default in LLVM. While there are no existing targets that take advantage of this the `wasm32-unknown-unknown` target will soon start to use this visibility. The LLD linker currently interprets `hidden` as "don't export this from the wasm module" which is what we want for 90% of our functions. While the LLD linker does have a "export this symbol" argument which is what we use for other linkers, it was also somewhat easier to do this change instead which'll involve less arguments flying around. Additionally there's no need for non-`hidden` visibility for most of our symbols! This change should not immediately impact the wasm targets as-is, but rather this is laying the foundations for soon integrating LLD as a linker for wasm code.
2018-01-30 11:54:07 -08:00
rustc: Allow using `clang` for wasm32 targets This commit adds support code for using `clang` directly to link the wasm32-unknown-unknown target. Currently the target is only really configured to link with LLD directly, but this ensures that `clang` can be configured as well. While not immediately useful in the near term it's likely that more wasm32 targets will pop up over time with Clang's new native support for WebAssembly in the 8.0.0 release. Getting support into rustc early should make it easier to experiment with these targets and try out various changes here and there.
2019-03-19 13:06:37 -07:00
// For now this target just never has an entry symbol no matter the output
// type, so unconditionally pass this.
clang_args.push("-Wl,--no-entry".to_string());
Format the world
2019-12-22 17:42:04 -05:00
options
.pre_link_args
.get_mut(&LinkerFlavor::Lld(LldFlavor::Wasm))
rustc: Allow using `clang` for wasm32 targets This commit adds support code for using `clang` directly to link the wasm32-unknown-unknown target. Currently the target is only really configured to link with LLD directly, but this ensures that `clang` can be configured as well. While not immediately useful in the near term it's likely that more wasm32 targets will pop up over time with Clang's new native support for WebAssembly in the 8.0.0 release. Getting support into rustc early should make it easier to experiment with these targets and try out various changes here and there.
2019-03-19 13:06:37 -07:00
.unwrap()
.push("--no-entry".to_string());
rustc: Allow targets to specify SIMD args are by-val The upcoming SIMD support in the wasm target is unique from the other platforms where it's either unconditionally available or not available, there's no halfway where a subsection of the program can use it but no other parts of the program can use it. In this world it's valid for wasm SIMD args to always be passed by value and there's no need to pass them by reference. This commit adds a new custom target specification option `simd_types_indirect` which defaults to `true`, but the wasm backend disables this and sets it to `false`.
2018-10-12 17:04:31 -07:00
rustc_target: Refactor away `TargetResult` Construction of a built-in target is always infallible now, so `TargetResult` is no longer necessary.
2020-10-05 15:37:55 +03:00
Target {
Upgrade to LLVM's master branch (LLVM 7) This commit upgrades the main LLVM submodule to LLVM's current master branch. The LLD submodule is updated in tandem as well as compiler-builtins. Along the way support was also added for LLVM 7's new features. This primarily includes the support for custom section concatenation natively in LLD so we now add wasm custom sections in LLVM IR rather than having custom support in rustc itself for doing so. Some other miscellaneous changes are: * We now pass `--gc-sections` to `wasm-ld` * The optimization level is now passed to `wasm-ld` * A `--stack-first` option is passed to LLD to have stack overflow always cause a trap instead of corrupting static data * The wasm target for LLVM switched to `wasm32-unknown-unknown`. * The syntax for aligned pointers has changed in LLVM IR and tests are updated to reflect this. * The `thumbv6m-none-eabi` target is disabled due to an [LLVM bug][llbug] Nowadays we've been mostly only upgrading whenever there's a major release of LLVM but enough changes have been happening on the wasm target that there's been growing motivation for quite some time now to upgrade out version of LLD. To upgrade LLD, however, we need to upgrade LLVM to avoid needing to build yet another version of LLVM on the builders. The revision of LLVM in use here is arbitrarily chosen. We will likely need to continue to update it over time if and when we discover bugs. Once LLVM 7 is fully released we can switch to that channel as well. [llbug]: https://bugs.llvm.org/show_bug.cgi?id=37382
2018-06-01 10:20:00 -07:00
llvm_target: "wasm32-unknown-unknown".to_string(),
Use integer literals for builtin target_pointer_width fields Also change target_pointer_width to pointer_width. Preparation for a subsequent type change of target_pointer_width to an integer together with a rename to pointer_width. On its own, this commit breaks the build. I don't like making build-breaking commits, but in this instance I believe that it makes review easier, as the "real" changes of this PR can be seen much more easily. Result of running: find compiler/rustc_target/src/spec/ -type f -exec sed -i -e 's/target_pointer_width: "\(.*\)"\..*,/pointer_width: \1,/g' {} \;
2020-10-14 18:08:12 +02:00
pointer_width: 32,
std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a "custom linker" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed, rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error, but anything related to allocation works (aka `HashMap`, `Vec`, etc). * Naturally, any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The "linking" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target, so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's "production ready". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored, but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the "smallest possible wasm module" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final "bloat" in vanilla rustc (again, a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this, particularly on the various integration points if you've got better ideas of how to approach them!
2017-10-22 20:01:00 -07:00
data_layout: "e-m:e-p:32:32-i64:64-n32:64-S128".to_string(),
arch: "wasm32".to_string(),
rust: Import LLD for linking wasm objects This commit imports the LLD project from LLVM to serve as the default linker for the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently removed along with "binaryen linker" support in rustc. Moving to LLD brings with it a number of benefits for wasm code: * LLD is itself an actual linker, so there's no need to compile all wasm code with LTO any more. As a result builds should be *much* speedier as LTO is no longer forcibly enabled for all builds of the wasm target. * LLD is quickly becoming an "official solution" for linking wasm code together. This, I believe at least, is intended to be the main supported linker for native code and wasm moving forward. Picking up support early on should help ensure that we can help LLD identify bugs and otherwise prove that it works great for all our use cases! * Improvements to the wasm toolchain are currently primarily focused around LLVM and LLD (from what I can tell at least), so it's in general much better to be on this bandwagon for bugfixes and new features. * Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which means a postprocessor is no longer needed to show off Rust's "small wasm binary size". LLD is added in a pretty standard way to rustc right now. A new rustbuild target was defined for building LLD, and this is executed when a compiler's sysroot is being assembled. LLD is compiled against the LLVM that we've got in tree, which means we're currently on the `release_60` branch, but this may get upgraded in the near future! LLD is placed into rustc's sysroot in a `bin` directory. This is similar to where `gcc.exe` can be found on Windows. This directory is automatically added to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd` linker which implements the interface that `wasm-ld`, LLD's frontend, expects. Like Emscripten the LLD target is currently only enabled for Tier 1 platforms, notably OSX/Windows/Linux, and will need to be installed manually for compiling to wasm on other platforms. LLD is by default turned off in rustbuild, and requires a `config.toml` option to be enabled to turn it on. Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD has a native option for controlling this. [gc]: https://reviews.llvm.org/D42511
2017-08-26 18:30:12 -07:00
linker_flavor: LinkerFlavor::Lld(LldFlavor::Wasm),
rustc: Allow using `clang` for wasm32 targets This commit adds support code for using `clang` directly to link the wasm32-unknown-unknown target. Currently the target is only really configured to link with LLD directly, but this ensures that `clang` can be configured as well. While not immediately useful in the near term it's likely that more wasm32 targets will pop up over time with Clang's new native support for WebAssembly in the 8.0.0 release. Getting support into rustc early should make it easier to experiment with these targets and try out various changes here and there.
2019-03-19 13:06:37 -07:00
options,
rustc_target: Refactor away `TargetResult` Construction of a built-in target is always infallible now, so `TargetResult` is no longer necessary.
2020-10-05 15:37:55 +03:00
}
std: Add a new wasm32-unknown-unknown target This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a "custom linker" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed, rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error, but anything related to allocation works (aka `HashMap`, `Vec`, etc). * Naturally, any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The "linking" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target, so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's "production ready". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored, but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the "smallest possible wasm module" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final "bloat" in vanilla rustc (again, a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this, particularly on the various integration points if you've got better ideas of how to approach them!
2017-10-22 20:01:00 -07:00
}
Reference in New Issue Copy Permalink