| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb] Move the generic MCP code into Protocol/MCP (NFC) (#152188) This moves all the generic MCP code into the new ProtocolMCP library so it can be shared between the MCP implementation in LLDB (built on the private API) and lldb-mcp (built on the public API). This PR doesn't include the actual MCP server. The reason is that the transport mechanism will be different between the LLDB implementation (using sockets) and the lldb-mcp implementation (using stdio). The goal s to abstract away that difference by making the server use JSONTransport (again) but I'm saving that for a separate PR. | 1 年前 | |
Avoid stalls when MainLoop::Interrupt fails to wake up the MainLoop (#164905) Turns out there's a bug in the current lldb sources that if you fork, set the stdio file handles to close on exec and then exec lldb with some commands and the --batch flag, lldb will stall on exit. The first cause of the bug is that the Python session handler - and probably other places in lldb - think 0, 1, and 2 HAVE TO BE the stdio file handles, and open and close and dup them as needed. NB: I am NOT trying to fix that bug. I'm not convinced running the lldb driver headless is worth a lot of effort, it's just as easy to redirect them to /dev/null, which does work. But I would like to keep lldb from stalling on the way out when this happens. The reason we stall is that we have a MainLoop waiting for signals, and we try to Interrupt it, but because stdio was closed, the interrupt pipe for the MainLoop gets the file descriptor 0, which gets closed by the Python session handler if you run some script command. So the Interrupt fails. We were running the Write to the interrupt pipe wrapped in llvm::cantFail, but in a no asserts build that just drops the error on the floor. So then lldb went on to call std:🧵:join on the still active MainLoop, and that stalls I made Interrupt (and AddCallback & AddPendingCallback) return a bool for "interrupt success" instead. All the places where code was requesting termination, I added checks for that failure, and skip the std:🧵:join call on the MainLoop thread, since that is almost certainly going to stall at this point. I didn't do the same for the Windows MainLoop, as I don't know if/when the WSASetEvent call can fail, so I always return true here. I also didn't turn the test off for Windows. According to the Python docs all the API's I used should work on Windows... If that turns out not to be true I'll make the test Darwin/Unix only. | 9 个月前 | |
[lldb] Adding A new Binding helper for JSONTransport. (#159160) This adds a new Binding helper class to allow mapping of incoming and outgoing requests / events to specific handlers. This should make it easier to create new protocol implementations and allow us to create a relay in the lldb-mcp binary. | 10 个月前 | |
[lldb] Adding structured types for existing MCP calls. (#155460) This adds or renames existing types to match the names of the types on https://modelcontextprotocol.io/specification/2025-06-18/schema for the existing calls. The new types are used in the unit tests and server implementation to remove the need for crafting various llvm::json::Object values by hand. | 11 个月前 | |
[lldb] Adding structured types for existing MCP calls. (#155460) This adds or renames existing types to match the names of the types on https://modelcontextprotocol.io/specification/2025-06-18/schema for the existing calls. The new types are used in the unit tests and server implementation to remove the need for crafting various llvm::json::Object values by hand. | 11 个月前 | |
[lldb-mcp] Adding a tool to list debuggers again. (#158340) This brings back the tool for listing debuggers. This is helpful when an LLM doesn't support resources, like gemini-cli. I also fixed an issue with ServerInfoHandle not always cleaning up the ~/lldb/lldb-mcp-<pid>.json file correctly. | 11 个月前 | |
[lldb-mcp] Adding a tool to list debuggers again. (#158340) This brings back the tool for listing debuggers. This is helpful when an LLM doesn't support resources, like gemini-cli. I also fixed an issue with ServerInfoHandle not always cleaning up the ~/lldb/lldb-mcp-<pid>.json file correctly. | 11 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 9 个月前 | ||
| 10 个月前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 11 个月前 | ||
| 11 个月前 |