Stream: wasmtime

Topic: debugging support?


view this post on Zulip Benjamin Bouvier (Apr 30 2021 at 15:29):

Hi! I'm trying debugging support in wasmtime, and i can run a rust crate compiled to wasm, debug it, and see the Rust code \o/
I've also discovered that we need to manually call vmctx.set(), which is fine. However, I sometimes get random values when inspecting variables, like self or some parameters. What's the status of debugging support in general?

view this post on Zulip Benjamin Bouvier (Apr 30 2021 at 15:29):

(Using latest wasmtime + lldb12)

view this post on Zulip Alex Crichton (Apr 30 2021 at 15:55):

afaik a lot of basics are there but it hasn't been super heavily battle-tested so there's likely missing pices

view this post on Zulip Alex Crichton (Apr 30 2021 at 15:55):

we have some but not a ton of tests, and this code hasn't seen much love in awhile

view this post on Zulip Chris Fallin (Apr 30 2021 at 15:58):

@Benjamin Bouvier in theory, it "should" be "correct" -- I implemented the analysis that computes locations from VCode and gives it to the debug crate -- but IIRC the debug crate is doing some wonky DWARF filtering/translation

view this post on Zulip Chris Fallin (Apr 30 2021 at 15:58):

anyway if it's showing wrong values (rather than just "unavailable" or "optimized out") then that's a bug and we should investigate

view this post on Zulip Chris Fallin (Apr 30 2021 at 15:58):

we don't make super-strong guarantees here but we should try to be correct :-)

view this post on Zulip Chris Fallin (Apr 30 2021 at 16:00):

also is this on aarch64? IIRC we only test so far on x86-64 (... so finding and fixing bugs on non-x86 is very useful, thank you!)

view this post on Zulip Yury Delendik (Apr 30 2021 at 16:01):

the "optimized out" often not a bug. it is by design -- debugging reserves that as a way to bail out from hard/complex cases

view this post on Zulip Chris Fallin (Apr 30 2021 at 16:04):

right, it sounds like the issue above is not "optimized out" but actually wrong values (?)

view this post on Zulip Yury Delendik (Apr 30 2021 at 16:04):

fwiw you will likely get "optimized out" because LLVM does not know or lost information about how to retrieve information about variable (which is hard by itself if you add operand stack nature of wasm) than due to wasmtime weird logic

view this post on Zulip Benjamin Bouvier (Apr 30 2021 at 16:13):

Yeah, in my case i'm debugging on x64, and seeing values that are incorrect when inspecting them: for instance a &self pointer is 0, or a parameter value is 0 (which is incorrect in my case) at the first line in the function, then becomes correct a few lines later, then becomes incorrect again

view this post on Zulip Benjamin Bouvier (Apr 30 2021 at 16:14):

Unfortunately don't have a small repro yet. But debugging is really important for us, so I'll try to make one quickly!

view this post on Zulip Chris Fallin (Apr 30 2021 at 16:15):

@Benjamin Bouvier this is a somewhat low-level answer but the RUST_LOG=debug output should include the debug value locations analysis (machinst/debug.rs) -- if you can deduce whether that's giving wrong answers or whether the DWARF manipulation is going bad, that would help significantly!

view this post on Zulip Yury Delendik (Apr 30 2021 at 16:18):

@Benjamin Bouvier I saw you are using __vmctx.set() (which is correct) Did you check https://github.com/bytecodealliance/wasmtime/pull/1482 ?

Currently, artificial "wrapper" types are created for pointer types. These wrappers display Wasm pointers as i32. To dereference such wrapper/pointer the function's vmctx is needed. T...

view this post on Zulip Benjamin Bouvier (Apr 30 2021 at 16:20):

@Yury Delendik thanks! i didn't see this. Should this show more if using pp instead of p?

view this post on Zulip Benjamin Bouvier (Apr 30 2021 at 16:21):

@Chris Fallin I'll try reducing first; the module has tons and tons of functions, so this might not be viable right now.

view this post on Zulip Yury Delendik (Apr 30 2021 at 16:21):

in most of the cases debugger needs to know vmctx -- dwarf expressions need to access wasm memory, and lldb/gdb has not way to do that in a good way

view this post on Zulip Yury Delendik (Apr 30 2021 at 16:22):

notice that pp is command regex pp 's/(.+)/p __vmctx->set(),%1/'

view this post on Zulip Benjamin Bouvier (Apr 30 2021 at 16:23):

@Yury Delendik Ah, is it required to run __vmctx->set() between each instruction? i might have missed that part!

view this post on Zulip Yury Delendik (Apr 30 2021 at 16:23):

you can use p but call __vmset.set() before first p (and context switches)

view this post on Zulip Benjamin Bouvier (Apr 30 2021 at 16:23):

right, so calling it once should be sufficient, i see


Last updated: Dec 23 2024 at 14:03 UTC