Feature request: GDB server for external tools

Sysprogs forums › Forums › VisualGDB › Feature request: GDB server for external tools

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #37458
    wtywtykk
    Participant

    Hi,

    I’m using AI agents to write code for MCUs, but I still need to debug by myself (press buttons etc.). And sometimes I want the agent to debug for me (like finding the source of a HardFault).

    Currently the GDB is exclusively used by VisualGDB, and OpenOCD can connect to only 1 GDB instance. So, the agent can’t use GDB. It chooses to access underlying data directly with OpenOCD, which is less efficient.

    Since you already provide an input box for manual GDB connection, could you add a feature like:

    • Listen on a network port and forward the commands/responses between internal GDB pipe and the network port.
    • Or even further, provide an MCP server with commands like gdb_send/gdb_acquire/gdb_release to avoid the data conflict between VGDB and the agent. (Not sure if this mechanism is really needed)

    Regards,

    Tianyi

    #37462
    support
    Keymaster

    Hi,

    Thanks for the suggestion! We are actually working on a similar thing with CodeVROOM, the stand-alone port of VisualGDB. We just got done with the debug timeline window, so it now keeps track of every step, breakpoint and other event, what variables were evaluated at each time, what other threads were doing, etc, allowing you to replay it and look back what the variable values were earlier. It also allows rigging breakpoints to record stacks/threads/variables and immediately continue.

    Letting the AI drive it will be one of the next steps. You will be able to give high-level instructions like “track down how the packet in ‘buf’ reaches the hardware, taking note of network headers added at each step”, and it will take control over the debugger, while recording every step. So, you’ll be able to either monitor what the AI is doing, and take control of it if needed, or step at your own pace through the recorded debug events it produces.

    There will be an MCP server eventually, but the first version will use the VisualGDB’s AI engine (works with any cloud or local model and doesn’t share any data with anyone else than the model’s endpoint).

    CodeVROOM is compatible with CMake-based VisualGDB projects; you can just download it here [CodeVROOM-0.8.0.375.exe], point it to a VisualGDB project, and it will pick up the existing BSPs, debug tools, etc. No installation needed, and it’s included in the VisualGDB license. If you are willing to try it, and can confirm that it works for your project, we can publish an updated version with basic AI-driven debugging support in about a week.

    Wiring it into Visual Studio would be harder. CodeVROOM’s debug engine was designed from the ground up to support multiple drivers and multiple observers. So, letting you examine a recorded event while AI is actively stepping through some other code works natively. Visual Studio cannot do that, and VisualGDB is already doing a lot of workarounds to handle special cases, so we woudn’t add any more complexity there. You can try making a gdb/mi proxy that will pretend to be a gdb executable to VisualGDB, and will also accept MCP connections, disconnecting VisualGDB from the actual GDB. But there will be lots of corner cases (in particular, with the order VS expects debug events), so it may end up being too buggy for production use.

     

    Attachments:
    You must be logged in to view attached files.
    #37464
    wtywtykk
    Participant

    Hi,

    Thanks for your reply!

    I tried CodeVROOM. Please find my feedback below:

    1. It works for my project, it loads and compiles, and debugging works.
    2. There seems to be a font fallback issue. For example, if I type “文字”, it becomes boxes. And if I change code editor font to Microsoft YaHei (the system default for Chinese, but not suitable for coding), it works. In VS, both Chinese and English can be shown even the font doesn’t support Chinese.
    3. The AI editing looks very different from other tools. In other agents, the LLM follows the ReAct pattern. It makes toolcalls after some reasoning, then plans the next steps. In this editor, it looks like the prompt is managed manually and everything is built to save tokens. The LLM only gets limited information and it can’t explore on its own. The model is trained on normal tool call formats, it’s having trouble understanding the custom output format. I tried some requests, but it doesn’t produce meaningful results.
    4. Chain-of-Thought (CoT) is not shown in AI diagnostics. (I’m using deepseek, and the CoT is not encrypted). Omitting CoT makes the session look like “freezed”.

    For now I’m not migrating to this new IDE. So there is no rush. I will try the proxy approach.

    Best Regards,

    Tianyi

     

Viewing 3 posts - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.