Enable native debugging for wasm modules/components #129
Conversation
syntactically
left a comment
syntactically
left a comment
There was a problem hiding this comment.
This looks great! If I understand it correctly, the actual "registering loaded code with GDB" is taken care of by the upstream wasmtime code that handles the GDB jit interface, which automatically works for us since when gdb loads the debug information for the sandbox binary, it gets the jit interface symbols from wasmtime?
One minor note that is not really completely related to this PR---this changeset made me notice that we still have a .vscode in this directory, which we removed from hyperlight core in hyperlight-dev/hyperlight#66. Do we want to remove that here as well, and make sure that any/all relevant settings are documented?
Thanks for taking a look at this. You are correct, the GDB jit interface is handled by the changes in wasmtime that enable it for I'll remove the .vscode, I don't have a strong preference. |
|
I'm a fan of keeping the .vscode for what it's worth. We brought it back in hl-core as well. |
Agreed, I don't think this impacts folks who don't care and helps those who do? |
|
Is the only thing blocking this waiting for a new wasmtime release that includes the debug features? |
dblnz
force-pushed
the
wasm-debug
branch
2 times, most recently
from
f66659c to
b5e07d0
Compare
dblnz
force-pushed
the
wasm-debug
branch
2 times, most recently
from
2c1be3a to
966c54b
Compare
|
I have discovered that the changes pending review do not allow wasm guests to be debugged any more. When placing a breakpoint in a I have debugged this issue to find out the root cause, and the problem is the fact that mapping the I have taken some time to investigate hyperlight-dev/hyperlight#747, and it I will come up with a fix for both as they have a common root cause. |
dblnz
force-pushed
the
wasm-debug
branch
4 times, most recently
from
349f9a8 to
9c0777d
Compare
dblnz
changed the title
dblnz
force-pushed
the
wasm-debug
branch
2 times, most recently
from
08ea922 to
7fdf0c8
Compare
dblnz
force-pushed
the
wasm-debug
branch
2 times, most recently
from
951817e to
2fe585e
Compare
ludfjig
left a comment
ludfjig
left a comment
There was a problem hiding this comment.
LGTM. Is the intention to merge this with the git refs in the cargo.toml, or wait for next version of hl to be released?
Signed-off-by: Doru Blânzeanu <dblnz@pm.me>
- The toolchain paths and flags are not correctly propagated on windows. When gdb feature is enabled, wasmtime-internal-jit-debug crate tries to compile C files using cc which is not correctly set on Windows Signed-off-by: Doru Blânzeanu <dblnz@pm.me>
…ging Signed-off-by: Doru Blânzeanu <dblnz@pm.me>
Signed-off-by: Doru Blânzeanu <dblnz@pm.me>
I'd like to get this as soon as possible, but as Hyperlight release is right around the corner, maybe we can wait |
I think we can merge this and then do an update when it comes out. We've done that in the past |
…g info Signed-off-by: Doru Blânzeanu <dblnz@pm.me>
5 participants
This PR address part of hyperlight-dev/hyperlight#684 and closes #120 that concerns the hyperlight-wasm related work to enable the wasm modules/components native debugging running in hyperlight-wasm guest.
What this includes:
debug-builtinsno_std feature ofwasmtimeintroduced by Allow compiling debug-builtins in no_std environment to enable gdb jit bytecodealliance/wasmtime#11304 which hasn't yet been mergedgdbfeature to enable support of debugging in host (hyperlight-host handles the connection to the debugger) and guest (concerns the settings ofwasmtimeto correctly report jit code to the debugger)