Wasker：将Wasm编译为原生ELF，让操作系统直接运行WebAssembly

1. 项目概述：Wasker，一个让操作系统成为Wasm运行时的编译器

如果你和我一样，对WebAssembly（Wasm）的潜力感到兴奋，但又对“运行时”这个中间层带来的性能开销和部署复杂性感到一丝无奈，那么Wasker这个项目可能会让你眼前一亮。简单来说，Wasker是一个编译器，它的核心工作是将标准的Wasm二进制文件（.wasm）编译成我们熟悉的ELF格式可执行文件（.o/.elf）。这听起来似乎和现有的wasm2c或一些AOT（提前编译）工具类似，但Wasker的独特之处在于它的“留白”艺术：它生成的ELF文件中，所有对WASI（WebAssembly系统接口）的调用都保持为未解析的符号。

这意味着什么？这意味着编译后的程序不是一个封闭的、绑定死特定运行时的黑盒。相反，它是一个“半成品”，等待着与具体操作系统提供的WASI实现进行链接。你可以把它想象成乐高积木：Wasker负责把Wasm代码这块积木塑造成标准的接口形状，而不同的操作系统（无论是Linux、Windows，还是像Mewz这样的unikernel）可以提供与之匹配的“底座”积木。最终，你的Wasm应用就能像原生应用一样，直接在你的“最爱”的操作系统上运行。Wasker的口号“Empower your favorite OS to serve as a Wasm runtime!”正是其精髓——它旨在消弭Wasm与原生系统之间的鸿沟，让操作系统本身成为Wasm的运行时。

2. Wasker的核心设计思路与架构解析

2.1 为何选择“未解析的WASI”作为突破口？

在深入代码之前，我们先聊聊设计哲学。当前Wasm生态中，运行一个Wasm模块通常需要一个“运行时”（Runtime），如Wasmtime、WasmEdge或Node.js。这些运行时负责提供WASI的实现、管理内存、执行字节码或编译后的机器码。这带来了两个问题：一是额外的抽象层必然引入性能开销（尽管已经很小）；二是部署时你需要捆绑或依赖这个运行时环境。

Wasker采取了一种更激进、也更贴近系统软件本质的思路：编译时链接，而非运行时解释。它不试图在编译阶段实现一个完整的、通用的WASI，而是将WASI调用视为一个个待填写的“占位符”（即未解析的符号）。这种设计带来了几个关键优势：

1. 极致的性能潜力：编译后的代码是纯粹的原生机器码，直接运行在硬件上，消除了传统运行时在指令调度、内存管理等方面的开销。WASI调用在链接后变成了直接的函数调用，甚至可能被操作系统内核内联优化。
2. 无与伦比的集成度：生成的ELF文件可以无缝融入现有的系统工具链。你可以用gcc、ld链接它，用gdb调试它，用perf分析它，就像对待任何一个C/C++/Rust项目一样。
3. 操作系统的主动权：不同的操作系统可以提供最适合自身内核架构和特性的WASI实现。例如，一个为实时系统设计的OS可以实现一个轻量级、确定性的WASI；而一个全功能服务器OS可以实现一个完整支持文件系统、网络的WASI。Wasker的输出是通用的，但最终的实现是高度定制化的。

2.2 Wasker的技术栈与工作流程

Wasker本身是用Rust编写的，这保证了其内存安全和高效的并发能力。它的核心依赖是LLVM 15，这是一个工业级的编译器框架。选择LLVM而非从头实现编译器后端，是一个明智的决定，它让Wasker能够直接利用LLVM成熟的优化器、代码生成器以及对多种指令集（x86-64, AArch64）的支持。

其工作流程可以清晰地分为以下几个阶段，如下图所示（对应项目中的架构图）：

+----------------+ +-------------+ +-----------------+ +-------------------+ | Input Wasm | --> | Wasm Front | --> | LLVM IR & Opt | --> | Object File Gen | | Binary/Text | | End | | (中间表示与优化) | | (生成.o文件) | +----------------+ +-------------+ +-----------------+ +-------------------+ | v +-------------------+ | ELF with Unres. | | WASI Symbols | +-------------------+ | v +-------------------+ | Link with OS | | WASI Wrapper | +-------------------+ | v +-------------------+ | Native Executable| +-------------------+

1. 前端解析：Wasker首先读取输入的Wasm二进制文件（或文本格式的.wat文件），将其解析为内部表示。这个过程会验证Wasm模块的合法性，并提取出函数、内存、表、全局变量等所有元素。
2. LLVM IR生成与优化：这是核心步骤。Wasker将Wasm模块的语义（函数控制流、内存访问、指令等）翻译成LLVM中间表示。在这个过程中，对于WASI的调用（例如fd_write,proc_exit），Wasker不会生成具体的实现代码，而是生成对外部符号的调用。例如，它会生成一个对名为wasi_snapshot_preview1.fd_write的函数的调用。这个符号在当前的编译单元（模块）中是未定义的。随后，LLVM的优化器会对生成的IR进行一系列优化，如常量传播、死代码消除、内联等，以提升最终代码的质量。
3. 目标文件生成：优化后的LLVM IR被传递给LLVM的后端，针对特定的目标架构（如x86_64-unknown-linux-gnu）生成机器码，并输出为标准的ELF目标文件（.o文件）。这个.o文件中包含了编译好的代码段、数据段，以及那个关键的未解析符号表，里面记录了所有需要外部提供的WASI函数。
4. 系统链接（用户完成）：用户或操作系统开发者需要提供一个“WASI包装器”。这个包装器是一个小的库或对象文件，它定义了那些Wasker留下的未解析符号。例如，在Linux上，wasi_snapshot_preview1.fd_write的实现可能会调用Linux的write系统调用。最后，使用系统链接器（如ld或通过gcc调用）将Wasker生成的.o文件与这个WASI包装器链接起来，生成最终的可执行文件。

注意：Wasker目前支持的是WASI Preview 1。这是一个重要的版本节点，它定义了相对稳定的系统调用集。未来随着WASI的演进（如Preview 2），Wasker也需要跟进支持新的API。

3. 从零开始实操：编译并运行你的第一个Wasm程序

理论说得再多，不如亲手跑一遍。我们完全按照项目提供的Quick Start流程走一遍，并补充一些背后的原理和可能遇到的坑。

3.1 环境准备与Wasker安装

项目提供了预编译的二进制文件，这是最快捷的方式。这条curl命令做的事情是：从GitHub Release下载对应版本（v0.1.1）的压缩包，解压，并将wasker可执行文件放置到/usr/bin/目录下。

curl -sSfL https://github.com/mewz-project/wasker/releases/download/v0.1.1/wasker-0.1.1-linux-$(uname -m)-gnu.tar.gz | tar -xzvC /usr/bin/ wasker

实操要点与避坑：

• 权限问题：写入/usr/bin需要sudo权限。如果你没有sudo权限，或者不想污染系统目录，可以修改命令，解压到本地目录，如~/.local/bin，并确保该目录在PATH环境变量中。

  mkdir -p ~/.local/bin curl -sSfL ... | tar -xzvC ~/.local/bin wasker export PATH=$PATH:~/.local/bin # 可以写入 ~/.bashrc 或 ~/.zshrc

• 架构与Libc适配：命令中的$(uname -m)会自动检测你的CPU架构（x86_64或aarch64）。预编译的二进制是动态链接到GNU libc的。这意味着它在标准的Linux发行版（如Ubuntu, Fedora）上应该能直接运行。但如果你在使用Alpine Linux（使用musl libc）或其他非GNU环境，可能会遇到链接错误。这时就需要按照“Development”部分的指引，从源码编译。
• 验证安装：安装后，运行wasker --help或wasker -V来确认安装成功。

3.2 准备Wasm输入文件

Wasker接受两种输入：二进制格式的.wasm文件和文本格式的.wat文件。项目提供了两个例子。

方案一：使用预制的简单例子这是最快的方式，直接使用项目仓库里的helloworld.wat。

git clone https://github.com/mewz-project/wasker.git cd wasker # 查看一下这个wat文件，它用文本格式定义了一个打印“Hello, World!”的Wasm模块。 cat helloworld.wat

方案二：从Rust源码构建Wasm如果你想体验完整的从高级语言到原生执行的过程，这个例子非常经典。

cd examples/rust # 添加 wasm32-wasi 编译目标。WASI是Wasm的系统接口，让Wasm能访问文件、网络等。 rustup target add wasm32-wasi # 以 wasm32-wasi 为目标进行编译。`--target` 参数告诉Cargo和rustc生成Wasm二进制。 cargo build --target wasm32-wasi

编译完成后，你会在target/wasm32-wasi/debug/目录下找到rust.wasm文件。这个Wasm模块包含了一个调用wasi_snapshot_preview1.fd_write来打印“Hello from Rust!”的程序。

为什么是wasm32-wasi？当我们用Rust写一个简单的println!(“Hello”)时，在标准平台上，它会最终调用操作系统的写API。当目标平台是wasm32-wasi时，Rust标准库会使用WASI的fd_write函数来实现这个打印功能。因此，生成的.wasm文件中就包含了对此WASI函数的调用。

3.3 运行Wasker进行编译

现在，让我们用Wasker来处理上一步生成的Wasm文件。

编译预制例子：

# 在wasker项目根目录执行 wasker helloworld.wat

你会看到类似以下的输出：

[2024-03-19T12:10:20Z INFO wasker::compiler] input: helloworld.wat [2024-03-19T12:10:20Z INFO wasker::compiler] write to ./wasm.ll [2024-03-19T12:10:20Z INFO wasker::compiler] write to ./wasm.o, it may take a while [2024-03-19T12:10:21Z INFO wasker::compiler] Compile success

编译Rust生成的Wasm：

wasker examples/rust/target/wasm32-wasi/debug/rust.wasm

关键输出文件解析：

1. wasm.ll：这是生成的LLVM中间表示（IR）文件，是人类可读的文本格式。你可以用文本编辑器打开它，看到里面有很多@wasi_snapshot_preview1.fd_write这样的外部函数声明。这个文件对于调试和理解编译过程非常有价值。
2. wasm.o：这是最终生成的ELF目标文件。你可以用file命令和objdump工具来检查它。

   file wasm.o # 输出：wasm.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped objdump -t wasm.o | grep UND # 这会列出所有未定义的符号，你应该能看到 wasi_snapshot_preview1.fd_write 等。

3.4 链接与运行：为Linux提供WASI实现

现在，我们有了一个包含未解析符号的wasm.o。要让它运行起来，我们需要提供一个具体的WASI实现来“填补”这些符号。项目在examples/wasi-wrapper/c/目录下提供了一个极简的Linux实现wasi-wrapper-linux.c。

让我们看看这个包装器的核心思想：

// 这是一个简化的示意，实际文件更复杂一些 __attribute__((used)) int wasi_snapshot_preview1.fd_write(int fd, const void *iovs, int iovs_len, int *nwritten) { // 这里将WASI的fd_write参数适配到Linux的writev系统调用 // 对于标准输出（fd=1），直接调用syscall if (fd == 1) { // ... 转换iovs结构 ... long ret = syscall(SYS_writev, fd, linux_iovs, iovs_len); *nwritten = (ret > 0) ? ret : 0; return (ret < 0) ? -errno : 0; } // 对于其他fd，可以返回错误码，如__WASI_ERRNO_BADF return -1; }

链接并生成最终可执行文件：

gcc -no-pie ./examples/wasi-wrapper/c/wasi-wrapper-linux.c ./wasm.o -o hello

• -no-pie：这个选项告诉链接器不要生成位置无关的可执行文件（PIE）。在某些情况下，Wasker生成的代码可能与PIE有冲突，加上这个选项可以避免链接错误。如果遇到relocation R_X86_64_32S against.textcan not be used when making a PIE这类错误，就是它了。
• wasi-wrapper-linux.c：提供了WASI符号的定义。
• wasm.o：Wasker编译出的包含主程序逻辑的目标文件。
• -o hello：输出最终的可执行文件hello。

运行！

./hello

如果一切顺利，你应该会看到Hello, World!（来自helloworld.wat）或Hello from Rust!（来自rust.wasm）输出在终端上。

这一刻的意义：你刚刚运行的程序，其源代码（Rust）被编译成Wasm，再由Wasker编译成原生机器码，最后链接了一个极薄的Linux适配层。它不再需要任何Wasm运行时，它就是一个纯粹的原生Linux进程。

4. 深入开发：从源码构建Wasker

预编译的二进制可能无法满足所有环境，或者你想贡献代码、了解内部机制，那么从源码构建是必经之路。Wasker的构建依赖于特定版本的LLVM（15.0.0）。

4.1 构建环境搭建

首先克隆仓库并进入目录：

git clone git@github.com:mewz-project/wasker.git cd wasker

4.2 安装指定版本的LLVM

Wasker通过llvm-sys这个Rust crate与LLVM C API交互，因此需要LLVM的开发库。项目文档提供了下载预编译LLVM的方法。

对于AMD64 (x86_64) 系统：

mkdir -p dependencies/llvm # 下载LLVM 15.0.0 for x86_64 wget https://github.com/llvm/llvm-project/releases/download/llvmorg-15.0.0/clang+llvm-15.0.0-x86_64-linux-gnu-rhel-8.4.tar.xz -O /tmp/llvm-15.0.0.tar.xz # 解压到项目依赖目录 tar -xvf /tmp/llvm-15.0.0.tar.xz -C dependencies/llvm # 设置关键环境变量，告诉Rust的llvm-sys crate去哪里找LLVM export LLVM_SYS_150_PREFIX=$PWD/dependencies/llvm/clang+llvm-15.0.0-x86_64-linux-gnu-rhel-8.4

对于AArch64 (ARM64) 系统： 命令类似，只是下载的包不同：

mkdir -p dependencies/llvm wget https://github.com/llvm/llvm-project/releases/download/llvmorg-15.0.0/clang+llvm-15.0.0-aarch64-linux-gnu.tar.xz -O /tmp/llvm-15.0.0.tar.xz tar -xvf /tmp/llvm-15.0.0.tar.xz -C dependencies/llvm export LLVM_SYS_150_PREFIX=$PWD/dependencies/llvm/clang+llvm-15.0.0-aarch64-linux-gnu

重要提示：LLVM_SYS_150_PREFIX环境变量必须在构建Wasker的整个会话中设置。你可以将其添加到你的shell配置文件（如~/.bashrc）中，或者确保在每次打开新终端构建时都设置它。

4.3 使用Cargo构建并运行

设置好环境变量后，就可以用Cargo来构建和运行Wasker了。

# 使用 cargo run 来编译并直接运行，传入 helloworld.wat 作为参数 cargo run -- helloworld.wat # 或者，先构建 release 版本的可执行文件 cargo build --release # 然后使用构建出的二进制 ./target/release/wasker helloworld.wat

构建过程详解：

1. Cargo会读取Cargo.toml，解析依赖。关键的依赖是llvm-sys = “15”。
2. llvm-sys构建脚本（build.rs）会检查LLVM_SYS_150_PREFIX环境变量，并在该路径下寻找include/llvm-c/（头文件）和lib/（库文件）。
3. 找到LLVM后，Rust编译器会编译Wasker的Rust代码，并链接到指定的LLVM库。
4. 最终生成wasker二进制文件。

常见构建问题排查：

• 错误：couldn’t find required LLVM component：这几乎总是因为LLVM_SYS_150_PREFIX设置不正确，或者指向的LLVM版本不是15.0.0，或者架构不匹配（例如在ARM机器上用了x86的LLVM包）。请仔细检查路径和下载的包。
• 错误：undefined reference to LLVM...：这是链接错误，同样是因为LLVM库路径问题。确保LD_LIBRARY_PATH环境变量可能也需要包含$LLVM_SYS_150_PREFIX/lib，但通常设置LLVM_SYS_150_PREFIX就够了。
• 内存不足：LLVM是一个庞大的框架，编译Wasker（特别是debug模式）可能会消耗较多内存（几个GB）。如果构建失败，尝试关闭其他程序，或使用cargo build --release（虽然更慢，但优化后内存使用模式可能不同）。

5. 高级应用场景与未来展望

Wasker的设计理念为其开辟了一些独特的应用场景。

5.1 与Unikernel（如Mewz）的完美结合

项目文档中提到了 Mewz ，这是一个unikernel操作系统。Unikernel的理念是将应用程序和必要的操作系统库编译成一个单一、轻量级、安全的镜像。Wasker与Unikernel是天作之合：

1. Wasker作为编译器：将用高级语言编写、编译为Wasm的业务逻辑，编译成包含未解析WASI符号的ELF对象文件。
2. Unikernel提供WASI实现：Mewz这类Unikernel在构建时，可以将一个轻量级的、直接映射到自身内核机制的WASI实现（包装器）链接进去。
3. 生成单一镜像：最终链接生成的是一个完全独立、不依赖外部运行时的可执行镜像。这个镜像可以直接在虚拟机或裸金属上启动，享受Unikernel带来的快速启动、微小体积和强安全边界的好处。

这为Serverless、边缘计算和嵌入式场景提供了一种新的、高效的Wasm部署形态。

5.2 为现有操作系统添加Wasm原生支持

操作系统发行版可以集成Wasker和一套对应的WASI系统库。想象一下，在未来某个Linux发行版中：

• 用户下载一个.wasm软件包。
• 包管理器自动调用wasker将其编译为.o文件。
• 在安装时，链接器将这个.o文件与发行版提供的libwasi.so（一个动态库形式的WASI实现）链接，生成一个标准的原生可执行文件。
• 用户就可以像运行任何其他程序一样运行它，完全无感于Wasm的存在。

这相当于为操作系统赋予了“原生执行Wasm”的能力，极大地简化了Wasm应用的分发和运行。

5.3 当前局限与挑战

当然，Wasker仍处于早期阶段（v0.1.1），有一些明显的限制：

• WASI版本：仅支持Preview 1。新的WASI API（如I/O流、HTTP）需要后续支持。
• 特性覆盖：Wasm的一些高级特性，如线程（Threads）、尾调用（Tail Call）、SIMD等，可能需要LLVM后端和Wasker前端的共同支持。
• 动态链接：目前生成的是静态链接的.o文件。对于复杂的、多模块的Wasm应用，如何支持动态链接是一个待解决的问题。
• 调试支持：如何将原生机器码的调试信息（如DWARF）映射回原始的Wasm或高级语言源码，是一个复杂的工程挑战。

5.4 给开发者的建议与贡献方向

如果你对Wasker感兴趣，除了使用它，还可以关注以下方向：

1. 完善WASI实现：为更多操作系统（如FreeBSD, Windows）编写健壮、高效的WASI包装器库。
2. 支持更多Wasm特性：参与实现Wasm多内存、引用类型等新特性在前端到LLVM IR的转换。
3. 工具链集成：开发与cargo、npm等包管理器集成的插件，实现一键“Wasm到原生”的编译。
4. 性能分析与优化：对比Wasker编译的程序与通过传统运行时（如Wasmtime AOT模式）执行的程序，分析性能差异，并优化LLVM的编译管道。

Wasker代表了一种将Wasm“落地”到传统系统软件世界的激进思路。它剥离了运行时的抽象，追求极致的性能和集成度。虽然前路还有不少挑战，但对于那些追求性能极限、渴望深度系统集成，或是在Unikernel等新兴领域探索的开发者来说，Wasker无疑提供了一个非常有趣且强大的工具。我个人在尝试将一些计算密集型的Wasm模块通过Wasker编译后，性能提升相当可观，尤其是在避免了运行时上下文切换和内存边界检查之后。如果你正在寻找一种新的Wasm部署方式，不妨花上半小时，跟着上面的步骤体验一下Wasker，它可能会改变你对Wasm应用执行方式的看法。