Stream: git-wasmtime

Topic: wasmtime / issue #9716 Debugging example from the docs wi...

Wasmtime GitHub notifications bot (Dec 03 2024 at 16:38):

bkolobara added the bug label to Issue #9716.

Wasmtime GitHub notifications bot (Dec 03 2024 at 16:38):

bkolobara opened issue #9716:

I'm trying to get the following example working inside of a debugger: https://docs.wasmtime.dev/examples-rust-debugging.html, but lldb can't read any of the local variables when a break point is triggered.

Test Case

The wasm file and executable are compiled directly from wasmtime examples.

> cargo build -p example-fib-debug-wasm --target wasm32-unknown-unknown
> cargo build --example fib-debug

Steps to Reproduce

Run the fib-debug executable inside lldb with the jit plugin enabled.

> lldb -- ./target/debug/examples/fib-debug
(lldb) target create "./target/debug/examples/fib-debug"
Current executable set to '/Users/bkolobara/dev/wasmtime/target/debug/examples/fib-debug' (arm64).
(lldb) settings set plugin.jit-loader.gdb.enable on
(lldb) b fib.rs:6
Breakpoint 1: no locations (pending).
WARNING:  Unable to resolve breakpoint to any actual locations.
(lldb) r
Process 87206 launched: '/Users/bkolobara/dev/wasmtime/target/debug/examples/fib-debug' (arm64)
1 location added to breakpoint 1
Process 87206 stopped

* thread #1, name = 'main', queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001041381c4 JIT(0x1381c8000)`fib(n=<unavailable>) at fib.rs:6:17
   3        let mut a = 1;
   4        let mut b = 1;
   5        for _ in 0..n {
-> 6            let t = a;
   7            a = b;
   8            b += t;
   9        }
Target 0: (fib-debug) stopped.
warning: This version of LLDB has no plugin for the language "rust". Inspection of frame variables will be limited.
(lldb) fr v
(WasmtimeVMContext *) __vmctx = <variable not available>

(unsigned int) n = <read memory from 0xffff8 failed (0 of 4 bytes read)>

(unsigned int) a = <no location, value may have been optimized out>

(unsigned int) b = <no location, value may have been optimized out>

(core::ops::range::Range<unsigned int>) iter = <no location, value may have been optimized out>

Expected Results

Running fr v in lldb in this context should display the values of the variables:

(unsigned int) a = 1

(unsigned int) b = 1

Actual Results

(unsigned int) a = <no location, value may have been optimized out>

(unsigned int) b = <no location, value may have been optimized out>

Versions and Environment

Wasmtime version or commit: 27.0

Operating system: macOs Sequoia 15.1.1

Architecture: Apple M1 Pro

Extra Info

> lldb --version
lldb-1600.0.39.3
Apple Swift version 6.0.2 (swiftlang-6.0.2.1.2 clang-1600.0.26.4)

There was a similar issue #3884, but it was closed as fixed 2 years ago.

I'm also aware that there is some work being done on improving the debug info translation in #5537.

Wasmtime GitHub notifications bot (Dec 04 2024 at 15:34):

alexcrichton commented on issue #9716:

cc @SingleAccretion since you've been looking at the DWARF stuff recently would you happen to recognize this?

Wasmtime GitHub notifications bot (Dec 04 2024 at 15:47):

SingleAccretion commented on issue #9716:

would you happen to recognize this?

Hmm, not immediately, considering this is trivial code at -Oopt-level=0. What is the Rust->WASM optimization level here?

Generically, non-trivial examples do fall apart very easily because SSA+RA do not preserve everything, and Cranelift preservation of variable ranges is quite poor.

The way to self-diagnose this is to look at the DWARF produced for WASM, check if a and b in it have reasonable ranges, then in LLDB do:

(lldb) image lookup -n fib --verbose

And check the coverage of the ranges that will be dumped.

Wasmtime GitHub notifications bot (Dec 04 2024 at 15:48):

SingleAccretion edited a comment on issue #9716:

would you happen to recognize this?

Hmm, not immediately, considering this is trivial code at -Oopt-level=0. What is the Rust->WASM optimization level here?

Generically, non-trivial examples do fall apart very easily because SSA+RA do not preserve everything, and Cranelift preservation of variable ranges is quite poor.

The way to self-diagnose this is to look at the DWARF produced for WASM, check if a and b in it have reasonable ranges, then in LLDB do:

(lldb) image lookup -r -n fib --verbose

And check the coverage for ranges that will be dumped.

Wasmtime GitHub notifications bot (Dec 04 2024 at 15:54):

SingleAccretion edited a comment on issue #9716:

would you happen to recognize this?

Hmm, not immediately, considering this is trivial code at -Oopt-level=0. What is the Rust->WASM optimization level here?

Generically, non-trivial examples do fall apart very easily because SSA+RA do not preserve everything, and so Cranelift's preservation of variable ranges is quite poor.

The way to self-diagnose this is to look at the DWARF produced for WASM, check if a and b in it have reasonable ranges, then in LLDB do:

(lldb) image lookup -r -n fib --verbose

And check the coverage for ranges that will be dumped.

Wasmtime GitHub notifications bot (Dec 04 2024 at 21:02):

bkolobara commented on issue #9716:

What is the Rust->WASM optimization level here?

This uses a debug build of the fib.rs file, so opt-level = 0, with debug info included.

Last updated: Dec 23 2024 at 12:05 UTC