Wasmtime: Modules built from Rust only work on Windows when built in release mode

[itowlson]

When I write a program in Rust and compile it to WASM, I cannot run it under wasmtime on Windows unless I passed the --release flag when I built it. If I built the WASM module in debug mode, wasmtime gives the error "command export '__rustc_debug_gdb_scripts_section__' is not a function". All other combinations of OS and build mode work: the error is specific to debug builds under Windows.

Steps to reproduce

1. Get hold of a Windows box. Install Rust, the wasm32-wasi target and wasmtime.
2. cargo new a hello-world program.
3. cd into the hello-world directory and cargo build --target wasm32-wasi
4. Run wasmtime run .\target\wasm32-wasi\debug\hello-world.wasm

Results

Expected: Should print Hello, world!

Actual:

Error: failed to run main module `.\target\wasm32-wasi\debug\hello-world.wasm`

Caused by:
    0: failed to instantiate ".\\target\\wasm32-wasi\\debug\\hello-world.wasm"
    1: command export '__rustc_debug_gdb_scripts_section__' is not a function

Environment

Windows 10, x64
Rust 1.40.0
Wasmtime 0.20.0

Additional information

• If I cargo build ... --release and use wasmtime to run the release build, it works.
• If I run the debug build on Linux (WSL Ubuntu), it works.

[tschneidereit]

Sounds like an issue with debug info handling. @yurydelendik, can you take a look?

[bjorn3]

__rustc_debug_gdb_scripts_section__ is exported by rustc to prevent LLVM from gcing a section that gdb reads to load the pretty printing python script for rust. That section normally contains the string gdb_load_rust_pretty_printers.py.

https://github.com/rust-lang/rust/blob/95b4a4f0eee935f9e0c80b0ceef34866bcb72ca3/compiler/rustc_codegen_llvm/src/debuginfo/gdb.rs#L37

Either Wasmtime should simply ignore this export instead of attempting to interpret it as command or rustc should stop adding this section for wasm.

[tschneidereit]

Thank you for the investigation, @bjorn3!

Either Wasmtime should simply ignore this export instead of attempting to interpret it as command or rustc should stop adding this section for wasm.

I think the former is preferable: we shouldn't rely on the compiler doing the right thing (assuming not adding this section would be the right thing, which I don't have enough context to know) about something like this.

[yurydelendik]

Looks unrelated to wasmtime debugging capabilities. Will the following help?

diff --git a/crates/wasmtime/src/linker.rs b/crates/wasmtime/src/linker.rs
index c22b89bf4..2f944050f 100644
--- a/crates/wasmtime/src/linker.rs
+++ b/crates/wasmtime/src/linker.rs
@@ -442,2 +442,5 @@ impl Linker {
                 warn!("command module exporting '__data_end' is deprecated");
+            } else if export.name() == "__rustc_debug_gdb_scripts_section__" && export.ty().global().is_some() {
+                // Allow an exported "__rustc_debug_gdb_scripts_section__" for compatibility with toolchains.
+                // See rustc logic for ".debug_gdb_scripts" section.
             } else if export.name() == "__heap_base" && export.ty().global().is_some() {

[workingjubilee]

If gdb (and specifically the rust-gdb pretty printer) can debug wasm, then rustc should (probably) continue adding the section for wasm targets. If gdb cannot debug wasm, then rustc should not add the section.
I don't know rust-gdb's limits here.