Wasm component module debugging - failure to step into the source code

[ggjjj]

bytecodealliance/wasm-tools#1854

I am using a rust application that launches the wasmtime with debug_info() set to true and loads a WASM module that implements component module.

I use wasm-tools to get the module adapted to wasi by
wasm-tools component new ./target/wasm32-wasip1/debug/module1.wasm -o ./tests/data/wasm-modules/processor-module1-$(VERSION).wasm --adapt wasi_snapshot_preview1.reactor.wasm

I also confirmed that the wasm-tools objdump to see that the debug_info information exists.

now once I launch the debugger for the rust application, I am only able to step into a call() function and but not in the wasm module source code.

is there any other step am I missing?

[ggjjj]

Configuration of wasmtime engine

let mut engine_config = Config::new(); engine_config .debug_info(true) .cranelift_opt_level(OptLevel::None) .wasm_component_model(true);

[ggjjj]

wasm-tools objdump of the module1 in question

bytecodealliance/wasm-tools#1854 (comment)

[ggjjj]

Do I need to include this feature "debug-builtins" in wasmtime crate to enable the debug symbols?

[ggjjj]

well adding the crate feature also did not help

[alexcrichton]

Would you be able to share snippets of the component/embedding in question? Or perhaps a snippet using the wasmtime CLI? It sounds like you're doing everything right, so it may come down to the details as to why this isn't working

[ggjjj]

Module Code

mod map_fah_to_cel {
    wit_bindgen::generate!({ path: "xxx", world "map-iml",});
    // we also use some SDK elements for the exports
    impl exports::xx:xx::xx:xx for Module {
    fn process(message_input) -> message_output
    }
    export!(Module);
}

[ggjjj]

App code that launches the runtime and loads the module and I am debugging this app

fn main() {
   thread::scope(|scope| {
        /*
         *  As wasm runtime & module have to be running on the same OS thread,
         *  use new_current_thread() to build a tokio runtime with the current
         *  thread scheduler selected.
         */
        let runtime = runtime::Builder::new_current_thread()
            .enable_all()
            .build()
            .unwrap();

        runtime.block_on(async_main(scope));
    });
}

async fn async_main(scope) {
   let mut engine_config = Config::new();
    engine_config
        .debug_info(true)
        .cranelift_opt_level(OptLevel::None)
        .wasm_component_model(true);
    let wasm_file_name: &str = "../../tests/data/wasm-modules/processor-module1-v1.wasm";
    {
         let wasm_component_info = &mut *wasm_component_info.lock();
         wasm_component_info.insert_component(&wasm_module_id, wasm_file_name.to_owned());
    }
// insert_wasm_module()
// call_map_fn()
// wait for wasm device manager by join()
}

[ggjjj]

My goal is to step into the source code of process() when the call_map_fn() is executed.

[fitzgen]

@ggjjj I appreciate that you provided some source code here, but it is incomplete and contains syntactical errors (eg no type on async_main's parameter).

Could you provide a git repo containing a fully self contained example that we can simply clone as well as detailed steps reproduce with exactly that git repo? Something like the following:

Minimal test case: url-of-git-repo

Steps to reproduce:

* clone git repo
* Run `cargo component build` inside the git repo
* Run `lldb -- wasmtime run -g path/to/test.wasm`
* step 5 times, until you reach the `foo` function

Expected Results

* You stepped through the `a.wasm::bar` function

Actual Results

* You never stepped through the `a.wasm::bar` function

The easier you can make it to reproduce the bug exactly, without needing to fix source code that doesn't build or infer steps that are implied but not explicitly described, the better we can help you and diagnose/resolve the bug that you are seeing.

Thanks!

[ggjjj]

I understand but we are working on private code. so is there any way I can debug this further? @fitzgen

[fitzgen]

Have you tried making a minimal reproducer that doesn't contain your private code?

[ggjjj]

I am trying that. Is this a sample that you recommend?

https://github.com/bytecodealliance/component-docs/blob/main/component-model/examples/example-host/src/add.rs

[fitzgen]

If you can get that example to reproduce your issue, then that sounds great. If you can't get that example to reproduce your issue, then I'd suggest trying to make calls and link modules/components together in a similar shape as your private code in an effort to find something that will reproduce the bug.

[ggjjj]

Sample tried - https://github.com/bytecodealliance/wasmtime/tree/main/examples/component

Steps followed

1. cargo build -p example-component-wasm --target wasm32-unknown-unknown
2. cargo run --example component

I was succesfully able to step into source code in guest.rs

Next I switched to wasm32-wasip1 target

Steps followed

1. cargo build -p example-component-wasm --target wasm32-wasip1
2. cargo run --example component

**Error: failed to decode world from module

Caused by:
0: module was not valid
1: failed to resolve import wasi_snapshot_preview1::fd_write
2: module requires an import interface named `wasi_snapshot_preview1**

[ggjjj]

My goal was to convert the module to adapt to wasi-preview1

by

wasm-tools component new ./target/wasm32-wasip1/debug/guest.wasm -o ./target/wasm32-wasip1/debug/guest-wasi.wasm --adapt wasi_snapshot_preview1.reactor.wasm

and use guest-wasi.wasm to load in main.rs of component
But I couldn't get to this step

[ggjjj]

I tried to use the guest-wasi.wasm in line53 of main.rs after the above wasm-tools command

let component = convert_to_component("target/wasm32-wasip1/debug/guest-wasi.wasm")?;
while running it, I got this error

**Error: decoding a component is not supported**

[ggjjj]

I used 25.0.2 snapshot file
https://github.com/bytecodealliance/wasmtime/releases/download/v25.0.2/wasi_snapshot_preview1.reactor.wasm

[ggjjj]

May I know why 26.0.0 is wasmtime version when only 25.0.2 is released?

[ggjjj]

@fitzgen Hey Nick did you get a chance to look at this one?

[alexcrichton]

@ggjjj it looks like there's a lot going on here with quite a few possibilities of what could be going wrong. We can try to piece together everything from the snippets of information you're posting but it'd be much more helpful to us as maintainers if you're able to do what Nick mentioned above with having a reproducible set of steps. It looks like you're trying a lot of things all at once and each thing is failing in different ways which may be unrelated to the original issue

[ggjjj]

Agree and apologize for including some many of the methods I tried in once. ok let me start step by step.

Goal 1 - Try the component example with wasm32-wasip1.

Minimal test case: url-of-git-repo

Steps to reproduce:

• clone git repo
• cargo build -p example-component-wasm --target wasm32-wasip1
• cargo run --example wasm32-wasip1

Expected Results

• Converted to 74.xxx

Actual Results

Error: failed to decode world from module

Caused by:
    0: module was not valid
    1: failed to resolve import `wasi_snapshot_preview1::fd_write`
    2: module requires an import interface named `wasi_snapshot_preview1`

[ggjjj]

@alexcrichton @fitzgen Is the above format okay? Is there any other information needed? Please advise