JDevlieghere wrote: I've been thinking about this too. I think you're right to distinguish two use cases:
1. Interacting with an existing debug session. For example you've started debugging in VS Code with DAP and you want your AI assistant to interact with the debug session. 2. Starting a new debug session. For example, you're working on a unit test and you want to run it under the debugger to see it crash so you ask your AI assistant to set a breakpoint and run the test under the debugger. The current implementation focuses on (1). I think (2) is a lot a harder, because depending on where I'm using this, I might want it to do something different. For example, from Claude desktop, I probably just want to have the model interact with the debugger behind the scenes. But in VS Code, I want to see the debug session in the IDE, and it should use DAP and from another IDE that doesn't support DAP, it might be something different. I think it's a useful use case, but currently not one I'm motivated to solve. That said, it does impact the design, so I think it should be considered so that we don't come up with something that's fundamentally incompatible. The second problem is that Claude assumes you have a single MCP server instance. VS Code works in a very similar way, though you can specify different servers per project. But you can have multiple concurrent active debug sessions per project, so we need a way to support that. Right now you need to use netcat with a fixed address and port and that's obviously a pretty awful user experience. What I had in mind for that (and hinted at in the RFC) is to create a binary, `lldb-mcp` that acts as a multiplexer and we use a known location (e.g. `~/.lldb-mcp`) where the sockets are created. The session ID then becomes an argument to every tool invocation. The tricky part is how to do the association. My hope is that with enough context (e.g. the currently active file in VS Code), the model will be smart enough to figure out the association between the MCP session, but I haven't tried anything like that. If we go with the multiplexing approach, then I think it's fine for every debugger to have its own server instance. If we do something different, it might make more sense to have one server per lldb instance and do the "multiplexing" there by just using the debugger ID. That would work for `lldb-dap` in server mode, but not when they're all separate processes. Another, even simpler, solution could be that we only support a single debug session (e.g. the last one) and ignore this problem for now. https://github.com/llvm/llvm-project/pull/143628 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
