Stream: git-wasmtime

Topic: wasmtime / issue #7278 View variables from shared memorie...


view this post on Zulip Wasmtime GitHub notifications bot (Dec 21 2023 at 03:46):

doinkythederp edited issue #7278:

Thanks for filing a feature request! Please fill out the TODOs below.

Feature

I'd like to be able to see the values of the variables in my Rust code that I've compiled to WASM when debugging with LLDB. Currently when using CodeLLDB to debug Rust compiled in debug mode, the only variable present is __vmctx.

Benefit

This would make it a lot simpler to debug incorrect state in programs and generally understand a misbehaving program.

view this post on Zulip Wasmtime GitHub notifications bot (Dec 21 2023 at 17:47):

abrown commented on issue #7278:

@doinkythederp, thanks for the codespace reproducer. Here's what I get when I follow your instructions:

![image](https://github.com/bytecodealliance/wasmtime/assets/541880/dc23a44a-0343-4549-9d18-5d8e2da8c11e)

It looks like, as @cfallin suggested, those values are being optimized away. But when I look at the WAT there seems to be enough there for proper debugging: example.wat.txt. So perhaps something is truly wrong with the DWARF here; I remember someone mentioning that that part of the codebase needs some maintenance attention.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 10 2024 at 22:06):

squillace commented on issue #7278:

Yup. wasmtime 18.02.
![image](https://github.com/bytecodealliance/wasmtime/assets/1422718/b4e860a9-f8f0-42fa-aee4-cb7aeffeb84f)

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2024 at 07:55):

pgherveou commented on issue #7278:

Hey there, I was trying to get this to work as well using wasmtime example, but it fails to print the variable as well,
it looks like this works though when you run the program through wasmtime binary

 lldb --version
lldb version 17.0.6

 lldb --batch -o "b  fib" -o "run" -o "fr v" -o "c"  ./target/debug/examples/fib-debug
(lldb) target create "./target/debug/examples/fib-debug"
Current executable set to '/home/pg/github/wasmtime/target/debug/examples/fib-debug' (x86_64).
(lldb) b  fib
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) run
1 location added to breakpoint 1
warning: This version of LLDB has no plugin for the language "rust". Inspection of frame variables will be limited.
Process 1334333 stopped

* thread #1, name = 'fib-debug', stop reason = breakpoint 1.1
    frame #0: 0x00007ffff76cc275 JIT(0x7fffef400010)`fib(n=<unavailable>) at fib.rs:3:17
   1    #[no_mangle]
   2    pub extern "C" fn fib(n: u32) -> u32 {
-> 3        let mut a = 1;
   4        let mut b = 1;
   5        for _ in 0..n {
   6            let t = a;
   7            a = b;
Process 1334333 launched: '/home/pg/github/wasmtime/target/debug/examples/fib-debug' (x86_64)
(lldb) fr v
(WasmtimeVMContext *) __vmctx = <variable not available>

(unsigned int) n = <variable not available>

(lldb) c
fib(6) = 21
Process 1334333 resuming
Process 1334333 exited with status = 0 (0x00000000)

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2024 at 13:44):

alexcrichton commented on issue #7278:

@pgherveou were you running with OptLevel::None and if not can you test that?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2024 at 15:55):

pgherveou commented on issue #7278:

@alexcrichton
I am running the example code from the repo.

do you mean that I should configure the config with cranelift strategy and set cranelift_opt_level to None ?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2024 at 15:58):

alexcrichton commented on issue #7278:

Indeed yeah, the strategy is default cranelift so you don't have to configure that unless you want, but OptLevel::None is not the default so you need to explicitly opt-in to that. This is something I just discovered myself a day or two ago, and if that fixes things for you I'll update the example/docs around this.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2024 at 16:09):

pgherveou commented on issue #7278:

mmm the doc does say it's the default though
https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.cranelift_opt_level

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2024 at 16:11):

pgherveou commented on issue #7278:

This does not seem to make a difference for me though, the output of the lldb script is the same as before.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2024 at 16:11):

pgherveou edited a comment on issue #7278:

mmm the doc does say it's the default though
https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.cranelift_opt_level

The default value for this is OptLevel::None.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2024 at 16:19):

pgherveou edited a comment on issue #7278:

This does not seem to make a difference for me though, the output of the lldb script is the same as before.
These are the commands that I fired:

cargo build --features debug-builtins --example fib-debug
cargo build -p example-fib-debug-wasm --target wasm32-unknown-unknown
lldb --batch -o "b  fib" -o "run" -o "fr v" -o "c"  ./target/debug/examples/fib-debug

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2024 at 19:41):

pgherveou commented on issue #7278:

Things works fine though if I simplify the fib function
to something as simple as

[no_mangle]
pub extern "C" fn fib(n: u32) -> u32 {
    return n + 3;
}

The C code compiled to wasm seems to work just fine as well too.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 06 2024 at 20:58):

alexcrichton commented on issue #7278:

Poking around locally I'm not sure what's going on as well. I spun out the issue into https://github.com/bytecodealliance/wasmtime/issues/8752 as an isolated version of the issue you're hitting.


Last updated: Dec 23 2024 at 13:07 UTC