Debugging: add debugger support for `wasmtime serve`. (#12859)This adopts a simple solution to #12776: it takes the "instance reuse"paradigm to the extreme, instantiating exactly one instance and
Debugging: add debugger support for `wasmtime serve`. (#12859)This adopts a simple solution to #12776: it takes the "instance reuse"paradigm to the extreme, instantiating exactly one instance andserializing all requests into that one instance. This allows thedebugger component to operate on one `Store`, setting breakpoint stateand presenting its execution to the attached debugger as a singleprogram execution and minimizing impedance mismatches.This also adds an integration test that runs an existing wasi-httptest component under the debugger.
show more ...
Debugging: add integration test with LLDB and some minor tweaks. (#12856)This PR adds:- An integration-test that runs LLDB against the Wasmtime CLI to verify basic debugging functionality, simi
Debugging: add integration test with LLDB and some minor tweaks. (#12856)This PR adds:- An integration-test that runs LLDB against the Wasmtime CLI to verify basic debugging functionality, similar to the existing native-debug tests.- A CI job that runs the above in CI.- Some minor tweaks to the gdbstub debugger design: - Rather than the initial single-step to get to the first Wasm instruction where module(s) will be instantiated into the store and visible to the debugger, we pre-register modules with the store eagerly. This avoids the slightly hacky flow and also is a preparation step for `wasmtime serve` debugging, where we can't single-step into execution eagerly (because execution doesn't start at all until an HTTP request arrives). - Add a separate message-printing path for "debugger info messages", allowing us to print the "debugger is listening on <PORT>" message without inheriting stderr for the whole debugger component environment. This message is necessary for the above integration test (it parses the message to determine when the debuggee is ready).