Steve Williams (Jun 26 2026 at 10:35): Steve Williams (Jun 26 2026 at 10:35):Query: https://claude.ai/chat/680d795a-2cc9-4fd5-a3d7-28a154d46113
If AI is correct (question is to confirm or otherwise), there's currently no way to enable "Guest-level gdbstub debugging" from the C API. No wasmtime_config_gdbstub_set or whatever to configure it. However the functionality is present in wasmtime.exe so I can just find what that's doing & patch my own in as a temporary until resolved completely or perhaps as a basis for that solution ?
Also status, please. From wasmtime.exe that's all working as expected & ready for production use or still under development & don't use yet ?
Thanks in advance & sorry for whining about this before - looks like we're in a much better place now.
Chris Fallin (Jun 26 2026 at 15:31):(Others can't see your claude chat link, but I'll go off of your human-written context)
The gdbstub component relies on a layer above core wasmtime + wasi, the wasmtime-debugger crate and the component world that it provides, and that hasn't been added to the C API yet. It's quite a lot more complex than just adding a bool flag though -- if you look at how wasmtime-cli integrates it, it needs separate toplevel logic to run the main execution inside of a scope in which the debugger is attached. You're welcome to try to put together something analogous but honestly it seems difficult -- would maybe involve a callback to run in a debugger scope or something like that.
In wasmtime-cli ("wasmtime.exe" on Windows) everything is working as expected and ready for production use. -g 1234 then attach LLDB to port 1234; see docs for more.
Steve Williams (Jun 26 2026 at 15:54):thanks chris, will push basic plumbing for this to my fork from trunk shortly, don't know what I'm doing regarding implementation yet, but do know the basic structure so perhaps one less job.
Steve Williams (Jun 26 2026 at 15:59):Got this - disclaimer - I am Rust noob & not all that familiar with this tree, especially the internals so perhaps a start, perhaps best done your way. Anyhow, a contribution. Compiles against trunk & gets me the entrypoint.
https://github.com/bytecodealliance/wasmtime/commit/5bed8d20b11e2f61d30758cddb8c2ab525792e97
Steve Williams (Jun 26 2026 at 16:02):to compile : -DWASMTIME_FEATURE_DEBUG_BUILTINS=ON -DWASMTIME_FEATURE_GDBSTUB=ON
Chris Fallin (Jun 26 2026 at 16:03):Hmm... that adds a new wasmtime::gdbstub, "Custom GDB stub implementation for guest debugging.", with a
// Your new gdbstub backend orchestration logic goes here!
todo!("Implement new gdbstub orchestration");
which is definitely not what we want:
Steve Williams (Jun 26 2026 at 16:04):we do this your way - I ran against the problem with AI assist to get something fast. as you're the expert, we go your way.
Chris Fallin (Jun 26 2026 at 16:04):That was far too fast to be human written so I presume you asked an agent to generate that? I would ask you to please instead (i) take the time to read our existing debug design (there are three RFCs), (ii) take the time to look at what we actually have, and then (iii) think carefully and design it yourself, before getting an agent to build it the wrong way and throwing it at us to review. Thanks!
Steve Williams (Jun 26 2026 at 16:05):not really a review, more it gets me in, now what.
Steve Williams (Jun 26 2026 at 16:05):& yeah, AI wrote most of that, I bashed it until it would compile & link. its not production code, its an early experiment.
Chris Fallin (Jun 26 2026 at 16:06):No, it does not get you in. It is the wrong direction, as described above. Please read the RFCs and the existing APIs.
Steve Williams (Jun 26 2026 at 16:07):k, so next step is to look at what wasmtime.exe actually does.
Chris Fallin (Jun 26 2026 at 16:07):Yes.
Steve Williams (Jun 26 2026 at 16:35):Should be able to see this one.
https://claude.ai/share/b45f871b-536d-457c-858a-3a15a1d66138
Sounds complex so not a done over the weekend task so I'll slow down & experiment as I have time. can't hit something complex hard right now as funding difficulties (not your problem - that's just why)
Steve Williams (Jun 26 2026 at 16:55):https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-debugging.md
Steve Williams (Jun 26 2026 at 17:13):Not a big deal, but typo in flowchart towards bottom of that page - Stepping not Steping
Steve Williams (Jun 26 2026 at 17:32):so, without getting into this, seems a refactor might be in order.
conceptually, whether via wasmtime.exe or the C API, we're doing the same thing, initializing the environment, connecting a debugger on some port, issuing commands & the thing runs or its at some breakpoint or whatever.
but basically its the same thing. so there should be a high level API for that & just plug it in both places.
if you use the "new" C API to drive wasmtime.exe functionality, I can do the same by making the same calls.
Steve Williams (Jun 26 2026 at 17:41):I'll need a tick function to run which can be part of my loop as need to run synchronously with some of our code, so can't just run async in your own thread, or at least not yet.
Steve Williams (Jun 26 2026 at 18:14):here for example, looks backwards to me.
we've got new_engine, load_module & so on in one call.
should be usual engine create, internally creating a debug view if it needs it, normal load_module, internally creating debug view if it needs it & so on, so the API flows as normal.
super early, I don't know my way around properly yet.
Chris Fallin (Jun 26 2026 at 18:17):@Steve Williams since others are subscribed to this channel, would you mind keeping the stream-of-consciousness separate from true questions? We can answer questions you have if they are directed at us, but statements-into-the-void are noise that take valuable maintainer time to parse and then decide how to respond or not. I believe you've gotten past warnings about this too. Thanks!
Steve Williams (Jun 26 2026 at 18:24):yup, but we're in omg what have you done zone. wasm has a clear c api with debugging capability requirement & you've gone off on one & implemented a different way in your non-standard .exe - that's fine for experimentation but not a final solution. this is relevant to everyone.
Steve Williams (Jun 26 2026 at 18:24):sounds like you've got the meat of a solution, its just in backwards.
Steve Williams (Jun 26 2026 at 18:25):the only new entry point that breaks the api that is required is passing in the port. for that, there needs to be a custom call or environment variable. other than that, should all be under the hood.
Chris Fallin (Jun 26 2026 at 18:30):Respectfully, you don't have full context. There was a year-long design process for Wasmtime's debug infrastructure. Wasm (the W3C standard) does not have one standard for debugging. We had a large set of requirements and we defined an infrastructure to support it.
You're approaching this for the first time, giving your AI agent the task of figuring it out for you, throwing slop at us, then your AI agent tells you to read the RFCs, you say (quote from your chat above) "ummm, you're the super intelligent AI. you're doing most of this".
You have a flagrant disregard for our time, and an incredible propensity to declare things Wrong after looking at them for half a second, without understanding Why. That's not a productive way of engaging with us. Please stop.
Steve Williams (Jun 26 2026 at 18:33):dude, there's a C API that we target & everyone else does. I appreciate flipping from what you have to something that tucks in neatly under that is non-trivial. its not personal, its architecture. if you've concluded that's not possible, how is 3rd party wasm code supposed to interact with what you've built ?
Steve Williams (Jun 26 2026 at 18:34):I have the utmost respect, by the way. what you've done looks super difficult & it sounds like you've pulled it off. its just not structured in a way I can interact with it & I'm not trying to be you. good modular design means I dont have to be.
Steve Williams (Jun 26 2026 at 18:36):its not wrong - if it works, it's right, it's just app centric not API centric. until it's API centric, its architecturally falling short.
Chris Fallin (Jun 26 2026 at 18:39):dude, there's a C API that we target & everyone else does.
Yes! And I believe it can be extended to support plugging in our debug components. I never said otherwise.
This is entirely about how you engage. You come in and declare everything wrong without having taken the time to understand why things are the way they are and what constraints and requirements we have. You even say (in your linked Claude chat above) that, when the agent prints a suggestion to read our RFCs, you reply "ummm, you're the super intelligent AI. you're doing most of this". That shows a flagrant disregard for putting in the work to engage properly. We will not have that here (and in fact we have policies against it: you cannot offload your design thinking and interactions to AI). Your blind spot here is preventing you from seeing why we built what we did, and instead quickly tossing it aside as "architecturally falling short".
Steve Williams (Jun 26 2026 at 18:42):we clash, everytime, even when I know this & try to be diplomatic. I can't work on this right now, in extreme difficulty that I won't bore you with. if we can't have debug capability in our 1.0 it'll have to ship without it & fix this later.
Steve Williams (Jun 26 2026 at 18:44):I didn't say everything is wrong - I read your design document & it seems much has changed. you've flipped from debugging doesn't matter to lets do this properly all the way - great to see :) I do respect all your hard work, Chris, its just a few twists from being a suitable replacement for the unreliable method we used to have.
Chris Fallin (Jun 26 2026 at 18:46):Well, no, I don't think we've ever said debugging doesn't matter. Our old (native-debugger) approach was always best-effort and we knew it had to be replaced. That is not the same as doesn't-matter.
In any case, best of luck. I hope you can spend the time to read through and understand why we built things the way we did, with debug-components on top rather than a "just expose the gdbstub port" API.
Steve Williams (Jun 26 2026 at 18:48):you know how you've built how you did & why. I'm not up to speed yet. are you saying supporting the C API is no longer possible & third party apps need to resolve some other way (we can change if necessary) or just that work isn't done yet (everything is a work in progress) ?
Steve Williams (Jun 26 2026 at 18:53):if a new program structure is required for engaging with your new debug interface, please can we have some C reference code demonstrating how we do that.
Chris Fallin (Jun 26 2026 at 18:56):I'm not up to speed yet.
Then it would probably be best not to immediately make judgments like "architecturally falling short."
are you saying supporting the C API is no longer possible & third party apps need to resolve some other way (we can change if necessary) or just that work isn't done yet (everything is a work in progress) ?
I'll repeat what I wrote above: "Yes! And I believe it can be extended to support plugging in our debug components. I never said otherwise."
please can we have some C reference code demonstrating how we do that.
There is no C API support yet. Building that is some nontrivial amount of work. I have a million other things on my plate that are higher priority so I probably cannot build this anytime soon. If you internalize the design, come up with a reasonable plan, present it to us and it makes sense, we could take a contribution.
Steve Williams (Jun 26 2026 at 18:58):Also have a zillion other things on. So it's possible, but neither of us have available resourcing. Not an ideal place to be, but not terrible either. Thanks for all you have done. Sorry I can't contribute more. At least not right now.
Steve Williams (Jun 26 2026 at 19:04):I suspect AI can do this. there's a completely solid design there - you have implemented it. the rest is plumbing. it probably can do this. especially the new models that are apparently available again.
Chris Fallin (Jun 26 2026 at 19:06):Please be aware of our AI tool policy: you are allowed to use agents to put together new work, but you must review it and understand it yourself in detail, and speak to us without an agent as an intermediary. That probably precludes "I don't have time but I can use an agent to bridge the gap" kind of thinking, FWIW. We say this because, again, our time is limited, Wasmtime code needs to be high-quality and reviewed and understood by humans, so we can't do that human-review work for contributors who can't do it themselves
Steve Williams (Jun 26 2026 at 19:13):totally get that & agree. that said, where work is already fully specified, its perhaps an area where the tools can help.
a migration plan would help. if neither of us have time, but we can put together a plan, that's at least part of the work done.
Plan
something like that breaks up the workload.
Chris Fallin (Jun 26 2026 at 19:15):You're more or less saying: let's design the API then. That's most of the work -- thinking through how one would provide a general wrapper around the existing wasm.h / wasmtime.h API that permits running within a debugger-attached store. If you have a proposal, please feel free to post it. Again I unfortunately do not have the time right now.
Steve Williams (Jun 26 2026 at 19:20):not quite, we have the API - the C API doesnt need to break & what it calls under the hood to access the Rust API likely doesn't change much either. I'm saying the working example (in wasmtime runtime) needs to morph to call those methods & those methods need extending to do the new stuff internally.
all I need from you right now is that won't work bcoz ... if there is a bcoz. if it will, its just doing the work & yeah, I'll do my bit.
Chris Fallin (Jun 26 2026 at 19:29):Well, no, we don't have a defined C API mapping for debugging. This is the whole thing I mentioned above about maybe taking a callback and running in the context of an attached debugger on a particular store. I don't know exactly what shape it should take, but there are careful semantics in the Rust API that someone needs to transfer over to C. I unfortunately don't have the bandwidth to do that right now, sorry.
Steve Williams (Jun 26 2026 at 19:32):can you point me at what the callback will be doing in the existing implementation ? if I'm understanding, the debugger needs its own thread for comms - that's easy enough. what's the callback doing ?
Chris Fallin (Jun 26 2026 at 19:35):Well, it's one way of implementing a scope in which a debugger is attached to a store; look at what the wasmtime-debugger crate is doing. "Fork off a background thread permanently" is another. The async implementations of all of this and how it reflects into C are also nontrivial.
Chris Fallin (Jun 26 2026 at 19:36):I really don't have more bandwidth here, sorry, this is turning into what our policies call an "extractive contribution" trying to draw a design out of me -- I'd encourage you to read the code, come up with a coherent proposal if you want, and come back to us when you have that
Till Schneidereit (Jun 26 2026 at 19:42):@Steve Williams as I have repeatedly done before, I'm asking you again to adjust your way of engaging here to the expectations communicated to you.
Chris has been showing substantial patience in continuing to engage with you here, and giving you concrete feedback to which parts of your way of engaging are problematic. The thing is, he shouldn't have to: you've been told all this multiple times before, and we're at a point where you have to take it to heart if you want to continue engaging on here. Please pause and really do so before even replying to this, as it's the last warning we'll give you before disabling your account here
Steve Williams (Jun 26 2026 at 19:46):once again I'm the bad guy for pointing out something isn't working the way it needs to.
I totally get other people have limited head space. me too.
Steve Williams (Jun 27 2026 at 11:37):First pass plumbing for C-API interface enhancements.
Renamed from gdbstub to dbg2 to avoid name clash with implementation.
https://github.com/bytecodealliance/wasmtime/compare/main...adv-sw:wasmtime:main
Builds with -DWASMTIME_FEATURE_DEBUG_BUILTINS=ON -DWASMTIME_FEATURE_DBG2=ON
Doesn't do anything yet. Doesn't clash with anything either.
Review not urgent, just where I'm at.
Probably doesnt go in yet as need to scope out full solution to even know how this ends up, but avoids anyone else having to do this too.
Chris Fallin (Jun 27 2026 at 16:53):Hi @Steve Williams -- once again this is the wrong approach unfortunately. We do not want a new debug API called dbg2. And the wasmtime-debugger crate provides a library API already to use debug components (wasmtime-cli is not special, any embedder can use it); the only thing that is missing is a C API binding to that crate. I'd encourage you to try that approach.
Steve Williams (Jun 27 2026 at 16:54):Trunk test.
Old debug method:
lldb -- .\wasmtime.exe -D debug-info .\fizz.wasm
b fizzbuzz
r
breaks as expected for me.
new way :
wasmtime run -g 1234 .\fizz.wasm
Debugger: Debugger listening on 127.0.0.1:1234
Debugger: In LLDB, attach with: process connect --plugin wasm connect://127.0.0.1:1234
then in another terminal
lldb
(lldb) process connect --plugin wasm connect://127.0.0.1:1234
Process 1 stopped
(lldb) b fizzbuzz
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) c
Runs app in primary terminal but breakpoint not hit.
Cannot use new debug method currently or I'm using it wrong, or my lldb too old.
Can you get me running with new system, please, then will inspect under the hood to see how to apply it to C API equivalent.
Steve Williams (Jun 27 2026 at 16:55):C API binding to use existing crate. ok.
Steve Williams (Jun 27 2026 at 16:59):could be I need a newer or special lldb. I'm on 22.0
Chris Fallin (Jun 27 2026 at 18:05):FYI, I am leaving on two-week PTO and will not be able to answer further until after (got one reply in while packing, now I’m truly out!). Others will need to help you, sorry
Christof Petig (Jun 27 2026 at 18:28):Please try the lldb included in wasi-sdk, that should be compatible.
Steve Williams (Jun 27 2026 at 18:35):thanks both - have a great vacation - we'll get thru this :)
Steve Williams (Jun 27 2026 at 18:53):thanks christof - that gets the debugger connecting properly. must use latest wasi-sdk lldb is the fix.
Steve Williams (Jun 29 2026 at 14:50):Some progress JIT debugging (testing on Windows) - NOT new remote debugging method.
Regular lldb 22 successfully hits JIT breakpoints using wasmtime trunk using our C API production code.
This lldb option is required - not just Mac as per wasmtime docs:
llib -o"settings set plugin.jit-loader.gdb.enable on" or however you want to set it.
Reason: lldb has a lazy JIT evaluator. Without this its luck whether it resolves before or after wasmtime has registered its DWARF debug data. Hence the instability we've all experienced. With this option my testing (Windows) has shown the situation resolves to robust.
The lldb in the latest wasi_sdk does not seem to support JIT debugging so for now need two versions of lldb depending on which debug method you wish to use. Assuming this is simply a compile time configuration but dont know the details yet. Ideally, would have one version that's solid & stable & supports both debug methods.
There's a new cranelift debugging method I wasn't aware of that reference code provides, so I've added that too.
wasmtime_config_debug_info_set(wasm_config, debug_mode); // Enable DWARF debug info
wasmtime_config_cranelift_opt_level_set(wasm_config, WASMTIME_OPT_LEVEL_NONE);
Unsure if its required, but as its in the reference code & our stuff is now hitting breakpoints, perhaps that was part of the problem.
Steve Williams (Jul 01 2026 at 08:08):JIT debugging - Windows.
wasi_sdk lldb on Windows doesnt support JIT debugging - thought at first it was a compile option but it's not as that stuff is built by default.
I had to patch to get it working.
Patch is : eSymbolTypeData -> eSymbolTypeAny
Tried to get submit to llvm ages ago but they wanted tests writing I don't have time for coz deep crunch so it never made it in.
Dunno if that's the issue current llvm trunk as haven't had time to build it yet, but suspect that's why current wasi_sdk lldb doesnt support JIT debugging on Windows.
Will build llvm trunk when I get a minute but figured should share this insight now.
Steve Williams (Jul 01 2026 at 08:27):I patched like this.
+#if defined WIN32 || defined WINDOWS || defined WIN64
eSymbolTypeAny);
+#else
eSymbolTypeData);
+#endif
Last updated: Jul 29 2026 at 05:03 UTC