[support]

Hi,

This could a bit tricky. VisualGDB uses two-level approach when indexing sources:

1. The solution can have one or more projects (top-level nodes in Solution Explorer, typically created by running the project wizard).
2. Every project can have one or more targets (individual static libraries, executables, etc.).

VisualGDB maintains a separate code index for each project, so it generally expects that every source file would only appear there once, regardless of the number of the underlying targets.

If you want to work with multiple instances of the same file built with different flags, you would need to restructure your solution into multiple projects. Then VisualGDB would detect that the file is used by several projects, and would allow choosing one via a combo box in the top left corner of the editor. However, that would create some complications (e.g. you would have a separate set of configurations/debug settings for each project, and you would need to be careful with inter-project dependencies).

Another option would be to have multiple build configurations (e.g. Debug-SDCard vs Debug-NoSDCard) and use CMake conditions to remove irrelevant targets from the configurations.

[support]

Hi,

The % syntax may not work correctly. We have updated VisualGDB to support the @-syntax in this build: VisualGDB-6.2.0.5619.msi.

E.g. /decover output.elf @inputs.rsp

If you are not sure what syntax Cmake is using, you can temporarily replace the custom command line with “cmd.exe ARGS /c echo VisualGDB.exe /decover …”. This will echo the actual VisualGDB command line instead of running it, so you can use it for troublehsooting.

[support]

Hi,

This could indeed be caused by the command-line length limit. VisualGDB’s code coverage support relies on patching all object files before the final linking takes place. This is defined in the coverage.cmake file under the VisualGDB\BSP directory:

add_custom_command(TARGET ${target_name} PRE_LINK COMMAND "$ENV{VISUALGDB_DIR}/VisualGDB.exe" ARGS /decover $<TARGET_FILE:${target_name}> ${_effective_sources})

If the _effective_sources list gets too long, it could indeed cause problems.

We can easily update VisualGDB to support the response file syntax (target name @<source list file>), but we are not aware of a straight-forward way to force CMake to use it for custom commands. You can try patching the CMake file on your end using temporary workarounds (e.g. manually generate a temporary list). If it works, we can easily upload an updated VisualGDB build with support for the @-syntax in that command.

[support]

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey

[support]

Hi,

Thanks for sharing this!

[support]

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey

[support]

Sure, here you go.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

We have rechecked it with the ESP-IDF 6.0.2 (default settings, default ESP32 device) and it worked just fine:

------------------- Memory utilization report -------------------
Used DATA_FLASH: 27KB out of 4096KB (0%)
Used INSTR_FLASH: 45KB out of 3264KB (1%)
Used DATA_RAM: 12KB out of 176KB (6%)
Used INSTR_RAM: 41KB out of 128KB (32%)
Used EXTERN_RAM: 0 bytes out of 4096KB (0%)
Used RTC_DATA: 0 bytes out of 8192 bytes (0%)
Used RTC_IRAM: 0 bytes out of 8192 bytes (0%)
Used RTC_SLOW: 40 bytes out of 8168 bytes (0%)
Used Unknown: 24 bytes

It could be something about that particular project that is causing the issue. Please consider reproducing it on a clean project created from scratch.

[support]

Hi,

Are you using Advanced CMake? The smart configurators are CMake-based, so they require the CMake build subsystem.

[support]

Hi,

Please try using File->New->Project/Solution and then searching for VisualGDB there. It should show the VisualGDB wizards just fine.

[support]

This could be a bug with the VS cache then.

You can try uninstalling VisualGDB, uninstalling VS2026, completely removing VS2026 directory, reinstalling VS2026, and reinstalling VisualGDB. This should fully reset all caches.

[support]

Hi,

If About VisualGDB command appears in both VS instances, the wizards should work as well.

You can double-check it by explicitly searching for “VisualGDB” in the wizard window, or using the separate File->New->VisualGDB Project command that just shows the wizards provided by VisualGDB.

[support]

Hi,

Please try completely  uninstalling VisualGDB, and then installing it back.

You can double-check the Help->About VisualGDB in both VS instances. If it is present, VisualGDB has been loaded successfully.

[support]

Hi,

We do not have that many Vitis users, so this is currently towards the end of the queue, after better STM32CubeMX integration and Renesas device support. If your company holds VisualGDB licenses, or your team is considering VisualGDB for the next project, feel free to reach out to our sales from your company email address, and we might be able to get it working faster.

[support]

https://visualgdb.com/documentation/falsepositives/

[Author]

Posts