WASAM compilation

The compilation process of Rust code to a WebAssembly (Wasm) module involves several steps. Here is an overview of the process:

1. Rust Code: Write the Rust code that we want to compile to a WebAssembly module. As we all know rust is a systems programming language that emphasizes safety, performance, and concurrency.

2. Cargo.toml: Create a Cargo.toml file in the project directory. This file contains metadata about Rust project and its dependencies.

Most of the .toml contents are familiar to use , but let me elaborate more on production release specific i.e [profile.release] section:

[lib]
crate-type = ["cdylib"]


[dependencies]
log = "0.4"
proxy-wasm = "0.2.1"

[profile.release]
lto = true
opt-level = 3
codegen-units = 1
panic = "abort"
strip = "debuginfo"        

The `[profile.release]` section in a `.toml` configuration file is used to specify the settings for the release build profile in Rust projects. Here's the meaning of each configuration option:

a. lto = true: LTO stands for "Link Time Optimization." When set to `true`, it enables Link Time Optimization, which allows the compiler to perform optimizations across different compilation units during the linking phase. This can lead to better performance but may increase the build time.

b. opt-level = 3: This option sets the optimization level for the release build. The value `3` is the highest level of optimization, which includes aggressive optimizations to generate the fastest possible code. It is recommended to use `opt-level = 3` for production releases.

c. codegen-units = 1: This option specifies the number of codegen units to use for the build. Codegen units determine how the compiler distributes the workload during code generation. Setting `codegen-units = 1` means that only one codegen unit will be used, which may reduce the build time but may not fully utilize multi-core CPUs.

d. panic = "abort": This option configures how the program should behave when a panic occurs. Setting `panic = "abort"` means that the program will abort immediately when a panic is encountered, resulting in a fast and clean termination. It's suitable for release builds where you want to avoid panics causing the program to continue running in an inconsistent state.

e. strip = "debuginfo": This option controls whether debug information should be included in the binary. Setting `strip = "debuginfo"` means that the debug information will be removed from the final binary, resulting in a smaller file size. This is typically done for release builds to reduce the binary size.

3. Cargo Build: Use the Cargo build system to compile your Rust code. Run the cargo build command in your project directory. Cargo will resolve and download the necessary dependencies, and then compile your Rust code into a native binary executable by default.

4. Target Specification: Specify the target platform for WebAssembly compilation. By default, Rust compiles for the native platform, but you need to specify the WebAssembly target to generate Wasm code. This can be done using the --target flag with the appropriate target specification. For example, --target wasm32-unknown-unknown specifies the target as WebAssembly.

5. Wasm Compilation: Use the Rust toolchain and the appropriate target specification to compile your Rust code to WebAssembly. Run the cargo build --target wasm32-unknown-unknown command to trigger the compilation process. Cargo will use the wasm32-unknown-unknown target specification to invoke the necessary toolchain and produce a WebAssembly binary.

6. Wasm Binary: After the compilation process completes successfully, you will have a WebAssembly binary (.wasm) file generated in the target directory. This binary contains the compiled code of your Rust program in a format that can be executed by WebAssembly runtimes.

7. Integration and Execution: The generated Wasm binary can be integrated into a larger project or executed using a WebAssembly runtime environment. You can use various tools and frameworks like Wasmer, Wasmtime, or the Web browser's JavaScript APIs to load and execute the Wasm module.

Below is detail w.r.t Compiler steps :

When Rust code is compiled to WebAssembly (Wasm), the compilation process involves several steps performed by the Rust compiler and other tools. Here are the key steps involved in the compilation process:

1. Frontend Parsing: The Rust compiler (rustc) starts by parsing the Rust source code into an abstract syntax tree (AST). This step involves analyzing the code's structure and identifying the syntax and semantics.
2. Type Checking: The compiler performs type checking on the parsed code to ensure that the types are used correctly and match the expected expressions and operations. This step verifies type compatibility and detects type errors.
3. HIR and MIR Generation: The compiler translates the AST into two intermediate representations: the High-Level Intermediate Representation (HIR) and the Mid-Level Intermediate Representation (MIR). These representations provide a more abstract view of the code, making it easier to analyze and optimize.
4. Optimization: The compiler applies various optimization techniques to the MIR representation to improve the code's performance and efficiency. Optimization passes include inlining, constant propagation, dead code elimination, loop optimizations, and more. The goal is to generate more optimized code that can be executed more efficiently.
5. LLVM IR Generation: The MIR representation is translated into LLVM Intermediate Representation (IR), which is a low-level, platform-independent representation. LLVM IR is a versatile format that allows further optimization and code generation targeting various architectures.
6. Cranelift-Codegen: If the Rust code is compiled for the WebAssembly target, the Cranelift-codegen backend may be used instead of LLVM. Cranelift is a code generation framework that specializes in generating highly optimized machine code for various targets, including WebAssembly. It offers an alternative to LLVM and is designed to produce efficient code specifically for WebAssembly execution.
7. Code Generation: The compiler generates the final machine code or WebAssembly binary based on the chosen backend (either LLVM or Cranelift). This binary includes the compiled instructions and data necessary to execute the program.
8. Linking and Packaging: The compiled code may need to be linked with other libraries or dependencies. This step ensures that all the required symbols and references are resolved and linked together. The resulting executable or WebAssembly module is packaged with the necessary metadata and headers for execution.
9. Output: The final output is the compiled WebAssembly binary (.wasm) file, which can be executed in a WebAssembly runtime environment or integrated into other systems.

It's important to note that the specific details of the compilation process can vary depending on the target platform, compiler settings, and any specific optimizations or customizations applied. The Rust compiler, along with tools like LLVM and Cranelift, work together to transform Rust code into efficient and executable WebAssembly modules.

The 6th step i.e Cranelift-Codegen is specific step for WASAM , so lets discuss little more about this .

The Cranelift project is an open-source project focused on developing a code generation library and framework for multiple programming languages and runtime systems. It aims to provide a high-performance, modular, and portable solution for generating machine code or intermediate representations (IR) from higher-level code representations.

In the context of the Rust programming language, the Cranelift project includes the cranelift-codegen crate, which is the code generation component of the Cranelift framework specifically tailored for Rust. The cranelift-codegen crate provides a set of APIs and utilities for generating machine code or IR from Rust code.

By using the cranelift-codegen crate, Rust developers can benefit from a flexible and efficient code generation infrastructure. It allows them to generate optimized machine code or WebAssembly binary code for specific target architectures or platforms. The Cranelift project emphasizes modularity and portability, enabling Rust developers to integrate code generation capabilities into their projects or compilers while maintaining performance and flexibility.

The Cranelift project, including the cranelift-codegen crate, serves as an alternative code generation backend for Rust, offering unique features and optimizations compared to other options like LLVM.

Cranelift is a code generator library and framework that provides a platform-independent, low-level code generation infrastructure. It is designed to be modular, fast, and easily portable to different platforms and architectures. Cranelift aims to provide a performant and flexible code generation solution for various languages and runtime environments, including WebAssembly.

cranelift-codegen is a Rust crate that implements the code generation functionality of the Cranelift framework. It provides a set of APIs and utilities for generating machine code or intermediate representations (IR) from higher-level code representations. The cranelift-codegen crate is often used as a backend for compilers and runtime systems that target specific platforms or architectures, including WebAssembly.

In the context of WebAssembly, cranelift-codegen can be used to generate efficient machine code or WebAssembly binary code from high-level languages like Rust, C, or others. It supports optimizations and code transformations to improve performance and produce compact and optimized code. cranelift-codegen can be integrated into a larger toolchain or compiler infrastructure to provide code generation capabilities for WebAssembly targets.

It's worth noting that cranelift-codegen is just one component of the Cranelift project, which also includes other crates and tools for handling IR, optimization passes, and machine-specific backends. These components work together to provide a flexible and extensible code generation solution.

Cranelift-codegen crate dont support the generation of webAssembly modules that interact with the WASI interface that target the Wasmtime

Example :

The below code demonstrates how to use the Wasmtime runtime to load, compile, and execute a WebAssembly module that interacts with the WASI interface.

Here's an overview of what the code does:

1. Import the necessary modules and functions from the wasmtime crate.
2. Create a new Wasmtime store to hold the runtime state.
3. Load and compile the WebAssembly module from the specified file path.
4. Create a new Wasmtime linker associated with the store.
5. Instantiate the WASI module and obtain the import object.
6. Add the WASI imports to the linker.
7. Instantiate the WebAssembly module by linking the module and WASI imports.
8. Get the function named "make_http_request" from the WebAssembly module.
9. Call the call function on the obtained function, passing the desired parameters (in this case, 0).
10. Handle the response code and perform further actions as needed.
11. Return a Result indicating the success or failure of the execution.

fn main() -> anyhow::Result<()> {
    // Create the Wasmtime store
    let store = Store::default();

    // Load and compile the WebAssembly module
    let module = Module::from_file(&store, "path/to/your/module.wasm")?;

    // Create the Wasmtime linker
    let mut linker = Linker::new(&store);

    // Define the WASI imports
    let wasi = Wasi::new(&store, WasiCtxBuilder::new().build()?);
    let wasi_imports = wasi.import_object(&module)?;

    // Add the WASI imports to the linker
    linker.extend(wasi_imports);

    // Instantiate the WebAssembly module
    let instance = linker.instantiate(&module)?;

    // Get the function that makes the HTTP request
    let http_request_func = instance
        .get_func("make_http_request")
        .ok_or(anyhow::format_err!("Function not found: make_http_request"))?
        .get2::<i32, i32>()?;

    // Call the function with the desired parameters
    let response_code = http_request_func.call(0)?;

    // Handle the response code and perform further actions

    Ok(())
}
        

The above demonstrates how to use the Wasmtime runtime to execute WebAssembly modules that interact with the WASI interface, enabling the module to make an HTTP request or perform other operations through the provided imports.

But the compilation fails :

cargo.toml

[dependencies]
wasmtime = "10.0.1"  # Replace with the desired version of Wasmtim
wasmtime-wasi = "10.0.1"  # Replace with the desired version of Wasmtime-Wasi
anyhow = "1.0.71"  # Replace with the desired version of the Anyhow cratee        

We will face below error:

amit@DESKTOP-9LTOFUP:~/proxyWasamSdk/wasm-env-example$ cargo build --target wasm32-wasi --release
   Compiling cranelift-codegen v0.97.1
   Compiling wasmtime-types v10.0.1
   Compiling cranelift-bforest v0.97.1
   Compiling unicase v2.6.0
error: failed to run custom build command for `cranelift-codegen v0.97.1`


Caused by:
  process didn't exit successfully: `/home/amit/proxyWasamSdk/wasm-env-example/target/release/build/cranelift-codegen-c80e9aeb0a55de8e/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'error when identifying target: "no supported isa found for arch `wasm32`"', /home/amit/.cargo/registry/src/github.com-1ecc6299db9ec823/cranelift-codegen-0.97.1/build.rs:43:53
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...        

The above error message indicates that the build process for the cranelift-codegen crate failed because it couldn't identify a supported instruction set architecture (ISA) for the wasm32 target.

This error can occur if the cranelift-codegen crate does not support generating code for the wasm32 target, which is the target architecture for WebAssembly modules.

Reason for compilation fail:

The Cranelift project, which includes the cranelift-codegen crate, does not currently support generating code for the wasm32 target directly. Cranelift is primarily designed for ahead-of-time (AOT) compilation scenarios and does not provide a WASI-compatible code generator.

If we need to work with the wasm32 target and WASI, you can explore other code generation options such as LLVM, which has better support for WASI and can generate code for the wasm32 target.

Alternatively, we can consider using the wasm-bindgen project, which provides a higher-level interface for interacting with WebAssembly modules in Rust. It simplifies the process of working with JavaScript and Web APIs from within the WebAssembly module. wasm-bindgen has better support for the wasm32 target and provides tools for generating bindings and working with JavaScript interop.

Thanks for reading till end , Please comment if you have any.