Stream: wasmtime

Topic: ✔ debugging: add breakpoint to emitted code


view this post on Zulip Vulcain (Aug 21 2024 at 13:03):

Hey :wave:
There is an issue with the emitted code, and I can't find what needs to change to make it work. It would help if I could run the output step by step and display registers, stack etc. Is it possible with lldb ? How can I add a breakpoint ?
Thanks :smile:

view this post on Zulip Ralph (Aug 21 2024 at 13:10):

components or wasi p1?

view this post on Zulip Ralph (Aug 21 2024 at 13:11):

if components: https://hachyderm.io/@squillace/112989210932769282

Attached: 1 video Back in March at #wasmio, @anfibiacreativa@mastodon.social and I showed a WIDE array of #webassembly debugging in #vscode: https://www.youtube.com/watch?v=sofGOtwGWu8. But, you'll note: the debugger couldn't navigate #webassemblycomponent files. Now it can!

view this post on Zulip Vulcain (Aug 21 2024 at 13:11):

wasi p1

view this post on Zulip Ralph (Aug 21 2024 at 13:11):

then that works even better:

view this post on Zulip Ralph (Aug 21 2024 at 13:12):

whether in vscode or not, the magic invocation is https://github.com/squillace/hello-wasi-http/blob/ff567823aed4451142f31bd0a90b196d576fabf7/.vscode/launch.json#L11-L17

simple repo to demonstrate how to debug Rust wasm components with wasmtime - squillace/hello-wasi-http

view this post on Zulip Ralph (Aug 21 2024 at 13:13):

lemme know how that works for you, because IT IS NOT PERFECT

view this post on Zulip Ralph (Aug 21 2024 at 13:13):

you can also use wamr debugger for wasi p1, but to do so I think you have to build llvm and lldb from scratch and apply a patch and then build the vscode extension... so, harder

view this post on Zulip Vulcain (Aug 21 2024 at 13:19):

Thank you, but my situation is a bit specific. I am working on winch, and dwarf has not been developed yet. Also, I don't have any source language, I just wrote the module in WAT

view this post on Zulip Vulcain (Aug 21 2024 at 13:24):

I have an llvm & lldb built from scratch on my machine, so I will try the wamr debugger

view this post on Zulip Vulcain (Aug 21 2024 at 13:33):

Ok, I can't debug the machine instructions emitted from another compiler with wamr. Thank you again for trying to help me

view this post on Zulip Ralph (Aug 21 2024 at 14:10):

ah

view this post on Zulip Ralph (Aug 21 2024 at 14:10):

yeah, that's interesting. It's almost like you need a debugger that steps through wat

view this post on Zulip Ralph (Aug 21 2024 at 14:11):

or the binary wasm, rather

view this post on Zulip Ralph (Aug 21 2024 at 14:12):

I think we'd need a wasm language server for that, which..... https://github.com/wasm-lsp/wasm-lsp-server is archived, so... hmmm.

A language server for WebAssembly. Contribute to wasm-lsp/wasm-lsp-server development by creating an account on GitHub.

view this post on Zulip Ralph (Aug 21 2024 at 14:13):

Geez, that would be helpful to have.

view this post on Zulip Vulcain (Aug 21 2024 at 14:40):

Yeah it would be cool, but I actually don't need source code mapping or any debug info at all. I just want to run the machine code (arm) step by step

view this post on Zulip Vulcain (Aug 21 2024 at 14:49):

image.png
I think it is possible because if I introduce a memory error, it actually stops in the guest code. I just don't know how to add a proper breakpoint

view this post on Zulip Ralph (Aug 21 2024 at 14:52):

actually, I think we might be able to make one that does this fairly easily.....

view this post on Zulip Ralph (Aug 21 2024 at 14:53):

if you use vscode, there's something called a "mock-debug" extension that implements step-by-step walkthrough using markdown. Functionally speaking, that could easily be modified to walk over WAT

view this post on Zulip Ralph (Aug 21 2024 at 14:53):

Vulcain said:

image.png
I think it is possible because if I introduce a memory error, it actually stops in the guest code. I just don't know how to add a proper breakpoint

oh wait, that's lldb

view this post on Zulip Ralph (Aug 21 2024 at 14:54):

dammit, I've done this....

view this post on Zulip Ralph (Aug 21 2024 at 14:55):

  1. breakpoint set -l <line-number> ; sets a breakpoint on a line in the current context.
  2. breakpoint set --file <file-name> -l <line-number> ; sets a breakpoint on a line on a given file.
  3. breakpoint set --name <method-name> ; sets a breakpoint on a given function name, globally.

view this post on Zulip Vulcain (Aug 21 2024 at 14:58):

Yes, but there is no file, I am trying to debug the arm code emitted by the winch compiler

view this post on Zulip Ralph (Aug 21 2024 at 15:00):

I was thinking the arm code was a text format, but if it's not, yeah -- you're sol there

view this post on Zulip Vulcain (Aug 21 2024 at 15:00):

Thank you again for trying !

view this post on Zulip Ralph (Aug 21 2024 at 15:02):

https://marketplace.visualstudio.com/items?itemName=Arm.arm-debugger ?????

Extension for Visual Studio Code - Arm Debugger for Arm Cortex-M based microcontrollers (MCUs), development boards and debug probes, implementing the Microsoft Debug Adapter Protocol (DAP)

view this post on Zulip Vulcain (Aug 21 2024 at 15:04):

I have no way to tell this extension where to add the breakpoint as the code does not exist before execution :oh_no:

view this post on Zulip Ralph (Aug 21 2024 at 15:04):

it would need to be run once the code is laid down so that sounds like an attach?

view this post on Zulip Ralph (Aug 21 2024 at 15:05):

at execution time, is the code just held in memory? not on the disk once created?

view this post on Zulip Ralph (Aug 21 2024 at 15:05):

I doubt I have a solution, just trying to imagine what one could look like.

view this post on Zulip Vulcain (Aug 21 2024 at 15:06):

I think so, but this is not a part of the codebase I am familiar with

view this post on Zulip Vulcain (Aug 21 2024 at 15:07):

I can compile AOT, but I don't think the debugger binds cwasm

view this post on Zulip Vulcain (Aug 21 2024 at 15:10):

My guess is it adds the generated code to the heap and jump to this address to execute the code. If it is what is happening, then I have to breakpoint this place. I don't know where it is though

view this post on Zulip Chris Fallin (Aug 21 2024 at 15:15):

@Vulcain if it helps, a technique that I've used to debug emitted-JIT-code issues is to insert artificial breakpoints (ud2 on Intel, udf on aarch64) by just... emitting them in sequence in the JIT compiler. Then I run the whole wasmtime process under gdb/lldb; I hit the breakpoint in the code; and (at least in gdb) you can "jump" over the opcode ($pc+2 on Intel, $pc+4 on aarch64) and single-step from there

view this post on Zulip Chris Fallin (Aug 21 2024 at 15:15):

very low-level and manual technique but it lets you examine the whole machine state

view this post on Zulip Saúl Cabrera (Aug 21 2024 at 15:16):

A technique that I usually use with LLDB in macOS is to put a breakpoint in https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasmtime/src/runtime/func.rs#L1073 (if you're invoking wasmtime from the CLI)

That should get you a debugger at where the function call starts. The complex thing about this approach is that you need to be familiar with how trampolines work in Wasmtime in order to navigate to the assembly of the Wasm function that you're trying to inspect.

A fast and secure runtime for WebAssembly. Contribute to bytecodealliance/wasmtime development by creating an account on GitHub.

view this post on Zulip Chris Fallin (Aug 21 2024 at 15:16):

separately, rr (the reversible debugger) is extraordinarily useful for things like these -- Mozilla developed it originally to debug Firefox and its JITs -- and it has certain CPU requirements, on x86 requires recent Intel chips, but I think it also supports Apple aarch64 CPUs if you're running native Asahi Linux (if that applies)

view this post on Zulip Vulcain (Aug 21 2024 at 15:19):

Saúl Cabrera said:

A technique that I usually use with LLDB in macOS is to put a breakpoint in https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasmtime/src/runtime/func.rs#L1073 (if you're invoking wasmtime from the CLI)

That should get you a debugger at where the function call starts. The complex thing about this approach is that you need to be familiar with how trampolines work in Wasmtime in order to navigate to the assembly of the Wasm function that you're trying to inspect.

That's the place I was looking for ! I will also try the udf technique, and take a look at rr. Thank you both for the info :grinning:

view this post on Zulip Notification Bot (Aug 21 2024 at 16:35):

Vulcain has marked this topic as resolved.


Last updated: Oct 23 2024 at 20:03 UTC