Benjamin Bouvier (Apr 30 2021 at 15:29): 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?
Benjamin Bouvier (Apr 30 2021 at 15:29):(Using latest wasmtime + lldb12)
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
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
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
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
Chris Fallin (Apr 30 2021 at 15:58):we don't make super-strong guarantees here but we should try to be correct :-)
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!)
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
Chris Fallin (Apr 30 2021 at 16:04):right, it sounds like the issue above is not "optimized out" but actually wrong values (?)
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
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
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!
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!
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 ?
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?
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.
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
Yury Delendik (Apr 30 2021 at 16:22):notice that pp is command regex pp 's/(.+)/p __vmctx->set(),%1/'
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!
Yury Delendik (Apr 30 2021 at 16:23):you can use p but call __vmset.set() before first p (and context switches)
Benjamin Bouvier (Apr 30 2021 at 16:23):right, so calling it once should be sufficient, i see
Last updated: Nov 22 2024 at 16:03 UTC