[support]

Thanks, this looks like a bug in the logic that is supposed to distinguish between side docks and document splits. We should be able to fix it in a couple of days. We’ll post an updated build here, and will also look into the other issues you reported.

[support]

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.

[support]

Thanks for the kind words! We have provided a detailed reply in this thread: https://sysprogs.com/w/forums/topic/keep-up-the-great-work/

[support]

Hi,

Thanks for the kind words and the feedback!

Both CodeVROOM and VisualGDB 6.1+ actually try to follow the ESP-IDF tool layout used by Espressif’s own tool installer. If you used Espressif’s VS Code extension on that computer, both VisualGDB and CodeVROOM will detect the tools installed by it, and if it’s a completely clean installation, they will download and install the tools, trying to follow the same directory structure as the original installer would do. You can check this tutorial – it shows the steps from the first run on a clean Linux machine to debugging a basic ESP32 project.

You can see the tools detected/installed by CodeVROOM via the link at the bottom of the ESP-IDF checkout selector (see attached file).

With the layout, it should normally be saved. There are actually 2 different mechanisms for the window layout:

• The full layout is saved to <workspace>\.sysprogside\<project name>\layout.xml and layout-debug.xml files with separate layouts for design and debug mode.
• The last used window locations are saved to %LOCALAPPDATA%\CodeVROOM\ToolWindowLocations.xml. So, if you move the Threads window from the bottom dock to the top dock in project A, and then open it for the first time in project B, it will remember the preferred position.

Based on what you are describing, something is interfering with the layout saving logic. We would appreciate it if you could try the following steps:

1. Open View->Diagnostic Windows->Diagnostic Console.
2. Try starting the debug session and opening one extra tool window.
3. Try stopping the debug session immediately.
4. Did the layout-debug.xml file get created under the .sysprogside directory? If not, are there any error messages in the diagnostic window?
5. If the file did get created, try making a copy of the file and starting the session again. This time, try opening another window and stopping the session. Is there anything different about the layout file?

You can also try the latest development build here: CodeVROOM-0.8.0.375.exe. It fixes a few glitches from v0.7, and introduces the new Debug Timeline window, that records all the debug stops together with the variables evaluated during them, and allows rigging breakpoints to record relevant data & immediately continue.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

This is actually planned for CodeVROOM, along with better GUI for embedded Python debugging. Given that a lot of the Rust community are Linux users, not being tied to Windows or Visual Studio should be a big advantage. But there are still more VisualGDB features that will need to be ported before adding more languages.

[support]

Hi,

Thanks for confirming your license. We have managed to reproduce the issue – it looks like a particular corner case with parsing a chain of DWARF debug type redirections.

We have fixed it in the stand-alone build [CodeVROOM-0.8.0.368.exe]. It supports opening CMake-based VisualGDB projects out-of-the-box, and the FreeRTOS queues are shown under Debug->Windows->RTOS Objects. If it fixes the problem, we will run a few checks on the VisualGDB build from the same branch, and will publish the hotfix here.

[support]

Thanks, we have reproduced the problem. Espressif indeed changed the internal layout of the tools in this version, so detecting gdb from the gcc path doesn’t work anymore. VisualGDB 6.1 was released when the old core layout was in place, so it won’t recognize the new one.

We have added support for the new core layout to the upcoming VisualGDB 6.2, however it is still a development build with a few rough edges here and there. You can try using the stand-alone version based on our CodeVROOM shell [CodeVROOM-0.8.0.367.exe] for the new ESP32 Arduino core, and keep VisualGDB 6.1 with Visual Studio for the other projects until v6.2 is more reliable. We can also publish the VisualGDB 6.2 build that includes the fix, but it cannot be installed simultaneously with v6.1.

[support]

Hi,

Switching configurations in VS is somewhat tricky. It involves a lot of work on different levels of Visual Studio itself, so adding extra steps there could break some of them.

So, we updated the checking logic to make a list of all toolchains referenced by all configurations/platforms, and if any of them is missing, you can substitute them individually. So, different configurations were using different toolchains, they will still be separate after the update.

We have currently added it to CodeVROOM (stand-alone port of VisualGDB). You can try this build: CodeVROOM-0.8.0.354.exe; it doesn’t need installation, you can just run the executable, open an existing .vgdbcmake project, and it will show the new substitution GUI if any missing toolchains are discovered. We will add this to the next VisualGDB update as well.

[support]

Hi,

No problem, we have just updated the ESP32 debug method package. You can install it via the VisualGDB Package Manager. The today’s version supports ESP32S31 out-of-the-box.

[support]

Hi,

Sure, you can change the CMake executable via VisualGDB Project Properties -> CMake Settings -> CMake command. You may need to clear the Tools->Options->VisualGDB->CMake->Use pre-built CMake for Local Builds setting if it does not override.

The Sysprogs extensions are mostly needed for the legacy CMake debugger, but the latest CMake supports debugging via the DAP protocol, and VisualGDB is going to support it in the next release as well, so there won’t be any need for the special CMake fork.

Update: you can try this build: VisualGDB-6.2.0.5630.msi. It supports the DAP-based CMake debugging, works out-of-the-box with CMake 4.x, and no longer suggests downloading the special fork.

[support]

Thanks for pointing this out, we have fixed it in this build: VisualGDB-6.2.0.5627.msi

We also just got Renesas support (including Live Variables and graphs) ported to CodeVROOM, so it now works outside Visual Studio as well (also, natively on Linux). Here’s an brand new tutorial: https://sysprogs.com/CodeVROOM/tutorials/renesas-ra/. Live Watch and plotting got a few upgrades compared to the Visual Studio-based GUI (e.g. live variables and graphs work with debug variable tooltips).

FWIW, CodeVROOM for Windows is included in the VisualGDB license, and uses the same project format, so you can use them interchangeably.

[support]

This should normally work just fine. If this is a big project that is already triggering internal linker errors, it could be that something else about it is producing an unexpected memory layout.

If you could share the ELF file, we can try loading it on our side to see why it’s triggering this error.

With screenshots, there should not be any major changes in the GUI since the documentation page was created. Feel free to attach a screenshot of the mismatching GUI, and we can check.

[support]

Hi,

This is possibly happening because the trace buffer variable is not inside a pre-initialized data section (e.g. .data, not .bss). See this page  (search for “pre-defined”) for an example.

With GCC, you can try creating a new project using our BSP (not STM32CubeMX or any other external generator). This way the frameworks GUI should work the same way.

[support]

Sure, the .vgdbsettings file has a straight-forward XML structure, so it should be trivial to patch it manually. However, the exact XML element to change would be different for different scenarios.

The easiest way to get it right would be to create a similar project using GCC, make a backup of the .vgdbsettings file, change the settings manually, and diff it against the previous version.

[support]

Sure, you can try enabling function tracing, setting the FLASH size via settings, and then disabling function tracing. Another option would be to just manually roll back the relocation record option after changing the Dynamic Analysis settings. The debugging settings are stored in the .vgdbsettings/.vgdbcmake files, while the linker flags (like relocation records) are stored in the CMakeLists.txt/.vcxproj files.

[Author]

Posts