Stream: git-wasmtime

Topic: wasmtime / issue #7278 View Rust variable values in LLDB

Wasmtime GitHub notifications bot (Oct 18 2023 at 01:59):

doinkythederp opened 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.

Wasmtime GitHub notifications bot (Oct 18 2023 at 02:10):

cfallin commented on issue #7278:

It's possible that #6960 would fix this issue for you (it's not yet in a release yet -- it looks like it just missed the cutoff for 13.0 in September, but it should be included in 14.0 on Oct 20). Could you try with a build from the latest main and see if your issue still occurs?

Wasmtime GitHub notifications bot (Oct 18 2023 at 02:10):

cfallin edited a comment on issue #7278:

It's possible that #6960 would fix this issue for you (it's not yet in a release -- it looks like it just missed the cutoff for 13.0 in September, but it should be included in 14.0 on Oct 20). Could you try with a build from the latest main and see if your issue still occurs?

Wasmtime GitHub notifications bot (Oct 18 2023 at 02:22):

doinkythederp commented on issue #7278:

Here's what it looks like with wasmtime @ 8e00cc202f82445a42adbad6e8187e901f91833b:
I read that it was necessary to run __vmctx->set() but it seems like that might be invalid syntax when debugging Rust?

Wasmtime GitHub notifications bot (Oct 18 2023 at 02:24):

doinkythederp edited a comment on issue #7278:

Here's what it looks like with wasmtime @ 8e00cc202f82445a42adbad6e8187e901f91833b:
I read that it was necessary to run __vmctx->set() but it seems like that might be invalid syntax when debugging Rust?

I am using .debug_info(true) in my wasmtime config and am compiling my WASM code in debug mode.

Wasmtime GitHub notifications bot (Oct 18 2023 at 03:26):

cfallin commented on issue #7278:

Are the values you're trying to show live at that location (i.e., will be used in the future)?

There is some optimization that goes on regardless of opt level just as a side-effect of going through SSA form, and register allocation; and the Rust + LLVM Wasm toolchain may be optimizing away values as well. It's hard to really say more without access to your module and a good chunk of time to dive into the IR, the DWARF, and the regalloc choices (sorry!).

Wasmtime GitHub notifications bot (Oct 18 2023 at 10:19):

bjorn3 commented on issue #7278:

Does __vmctx.set() or (*__vmxtx).set() work? At least gcc switches to the rust syntax for the print command when the current frame is marked as written in rust. I don't know if that is the case with clang too.

Wasmtime GitHub notifications bot (Oct 18 2023 at 10:19):

bjorn3 edited a comment on issue #7278:

Does __vmctx.set() or (*__vmxtx).set() work? At least gcc switches to the rust syntax for the print command when the current frame is marked as written in rust. I don't know if that is the case with lldb too.

Wasmtime GitHub notifications bot (Oct 20 2023 at 01:56):

doinkythederp commented on issue #7278:

Hi, I have an update: I've been working on getting a minimal demonstration of the situation and I stumbled upon the discovery that variables do show in the debugger menu, but only when not using WASM threads/shared memory. For my use cases, I need WASM threads as I'm emulating the FreeRTOS task-switching mechanism. I've made a Dev Container that shows this behavior: https://github.com/doinkythederp/wasmtime-repro

Wasmtime GitHub notifications bot (Oct 20 2023 at 02:01):

doinkythederp edited a comment on issue #7278:

Hi, I have an update: I've been working on getting a minimal demonstration of the situation and I stumbled upon the discovery that variables do show in the debugger menu, but not using WASM threads/shared memory. For my use cases, I need WASM threads as I'm emulating the FreeRTOS task-switching mechanism. I've made a Dev Container that shows this behavior: https://github.com/doinkythederp/wasmtime-repro

Wasmtime GitHub notifications bot (Oct 20 2023 at 05:57):

doinkythederp edited a comment on issue #7278:

Hi, I have an update: I've been working on getting a minimal demonstration of the situation and I stumbled upon the discovery that variables do show in the debugger menu, but not when using WASM threads/shared memory. For my use cases, I need WASM threads as I'm emulating the FreeRTOS task-switching mechanism. I've made a Dev Container that shows this behavior: https://github.com/doinkythederp/wasmtime-repro

Wasmtime GitHub notifications bot (Oct 20 2023 at 05:58):

doinkythederp edited a comment on issue #7278:

Hi, I have an update: I've been working on getting a minimal demonstration of the situation and I stumbled upon the discovery that variables only show in the debugger menu when not using WASM threads/shared memory. For my use cases, I need WASM threads as I'm emulating the FreeRTOS task-switching mechanism. I've made a Dev Container that shows this behavior: https://github.com/doinkythederp/wasmtime-repro

Wasmtime GitHub notifications bot (Dec 21 2023 at 03:45):

doinkythederp commented on issue #7278:

Hi, I'm just checking back in to ask if there are any plans to fix variable debugging when using SharedMemory. This is important to me because it limits the work I can do with WASM threads. Is this planned? Is it an issue with LLDB itself? I don't have much experience in dealing with debug info or debugger internals so I don't think I'd be able to make any required contributions myself.

Last updated: Dec 23 2024 at 12:05 UTC