Forum Replies Created
-
Posts
-
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.
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
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
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.
Hi,
Are you using Advanced CMake? The smart configurators are CMake-based, so they require the CMake build subsystem.
Hi,
Please try using File->New->Project/Solution and then searching for VisualGDB there. It should show the VisualGDB wizards just fine.
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.
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.
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.
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.
Hi,
OK, we have reproduced the issue. Switching the IntelliSense engine from MSVC to Clang involves re-creating a few relatively complex structures required for backward compatibility. It looks like something about the order in which they are re-registered interferes with filtering of keystrokes.
You can try a couple of workarounds:
- Try changing the suggestion list GUI via Tools->Options->Text Editor->C/C++(VisualGDB)->Advanced->Code Completion->Smart Suggestion List GUI. Simpler GUI modes do not depend on the advanced filtering.
- Re-opening the file (or the entire solution) will automatically do a clean reset of the keystroke filters, so you don’t need to restart VS entirely.
That said, switching between Clang IntelliSense and MSVC IntelliSense is mostly intended for diagnostic purposes, and is expected to be done infrequently. Is there any reason you are often switching back and forth between them? We are working on a few optimizations related to caching of the sources and the Go-to-Definition command, so if you are switching away from Clang to work around issues with these commands, we might have a better fix for you.
