support

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 7,900 total)
  • Author
    Posts
  • in reply to: Embedded Memory Explorer Name Demangling Fails #37070
    support
    Keymaster

    No problem. Could you please check whether it works with the c++filt.exe executable from our latest MinGW toolchain?

    If not, does it work with any other c++filt version?

    support
    Keymaster

    Hi,

    Normally, the quick info mode should not affect reparse times. We have just rechecked it as follows:

    1. Created a new project from scratch (Embedded STM32, Advanced CMake)
    2. Enabled Clang IntelliSense Diagnostics Console
    3. Tried adding one empty line at a time to the main source file, observing the diagnostics console for reparse messages (Starting operation: Parse)
    4. Triggered a Quick Info popup and switched it to References
    5. Closed the popup and tried adding empty lines again

    In both cases, the file is reparsed whenever you make a large enough break between adding new lines (or when you explicitly save the file). To be more precise, VisualGDB keeps a track on how long it took to parse the file last time, so it waits until there are no edits to the file for 5x the last parse time before it triggers another parse. It should not be related to Quick Info, but can appear inconsistent if the parse time varies between iterations.

    Either way, you can fully tweak this behavior via Tools->Options->Text Editor->C/C++ (VisualGDB) -> Adaptive Reparse. E.g. set the additional delay, or the minimum reparse interval.

    in reply to: Embedded Memory Explorer Name Demangling Fails #37060
    support
    Keymaster

    OK, we have rebuilt the demangler DLL based on GCC 15.2, and also updated our MinGW toolchains based on that version.

    Feel free to try this build: VisualGDB-6.1.101.5494.msi

    in reply to: rpi64 trixie toolchain? #37058
    support
    Keymaster

    Hi,

    OK, we got through the backlog and released the updated versions of both the 32-bit and the 64-bit toolchains.

    in reply to: New Device Support #37056
    support
    Keymaster

    Hi,

    Based on what we see, your support has expired. We are currently working on several other updates requested by paid users, and do not have a timeline for STM32N6.

    Please consider renewing your license if you would like to get a time estimate.

    in reply to: Embedded Memory Explorer Name Demangling Fails #37049
    support
    Keymaster

    Hi,

    No problem, the demangler is already a separate DLL with a very simple interface (demangle.dll/demangle64.dll).

    #include <cxxabi.h>
    #include <stdlib.h>
    
    extern "C" char *__declspec(dllexport) DemangleCXXName2(const char *pName)
    {
    int status = -1;
    return abi::__cxa_demangle(pName, 0, 0, &status);
    }
    
    extern "C" void __declspec(dllexport) FreeDemangledCXXName(char *pName)
    {
    free(pName);
    }

    You can build with MinGW using the following command line:

    g++.exe demangle.cpp -o demangle.dll -shared -static-libgcc -static-libstdc++

    We will update the version shipped with VisualGDB based on the latest MinGW toolchain in the final v6.1 release.

    in reply to: Super Disappointed #37036
    support
    Keymaster

    Hi,

    Sorry for your disappointment. We do not have a toolchain for Trixie yet, hence the warning about lsb_release. You can try downgrading to the Bookworm SD card image (the compatible versions are listed here), building the code directly on Raspberry Pi, or using WSL with the Raspberry Pi’s own toolchain (if they provide one).

    We have never encountered ld getting stuck forever on a hello world project. That said, if you ignored the lsb_release warning and resynchronized the toolchain’s sysroot, you would end up with a combination of tools and libraries that was never meant to work together, and that could result in completely unpredictable behavior.

    If you are not sure, please try completely deleting the toolchain, and starting from a clean SD card image (make sure it matches the toolchain).

    support
    Keymaster

    Hi,

    VisualGDB’s CMake framework uses regular CMake commands. You can find a detailed reference of them here: https://cmake.org/cmake/help/latest/manual/cmake-commands.7.html.

    That said, we had to handle a lot of corner cases to make sure everything works out-of-the-box, so if you would like to have your own parallel system, you will likely have to do a lot of research and troubleshooting.

    support
    Keymaster

    Hi,

    VisualGDB uses the regular CMake for its projects. You can actually find the sources for the functions like add_bsp_based_library() in %VISUALGDB_DIR%\CMake\embedded.

    The motivation behind using the add_bsp_based_executable() was to allow having multiple BSPs per project. A BSP defines compiler flags, include directories, etc., and every executable/library that uses that particular BSP automatically receives these flags.

    If you absolutely want to override this mechanism and have your own global flags, you can easily add your own CMake functions either to the project’s CMake files, or to some shared files imported from the projects. E.g. you can see how add_bsp_based_executable() loads the BSP’s CFLAGS, and implement something similar.

    in reply to: Attach to process #37025
    support
    Keymaster

    Hi,

    There are 2 ways to attach to a process from VisualGDB:

    1. Using the regular Debug->Attach command in Visual Studio. We have a tutorial here demonstrating how to do it.
    2. You can also configure the project to automatically attach to an existing process instead of launching a new one via VisualGDB Project Properties -> Debug Settings. This way, you can retain other project-specific settings like path mappings, or additional GDB commands.
    in reply to: Intellisense issue with Directory Symbolic links #37008
    support
    Keymaster

    OK, we have added special handling for symlinked directories to this build: VisualGDB-6.1.5.5477.msi

    The only caveat is that go-to-definition (F12) and find references (Shift-F12) will always open the actual file locations, so you may end up with 2 copies of the same file open. All other functionality (syntax highlighting, outline, etc) now works the same way for both symlinked and actual physical paths.

    in reply to: Intellisense issue with Directory Symbolic links #37007
    support
    Keymaster

    Hi,

    Thanks for reporting this. Looks like the new Clang indeed handles the symlinked files differently. We will run a few more experiments and will publish a hotfix in the next couple of days.

    in reply to: Use existing RPi OS? #37003
    support
    Keymaster

    The sysroot synchronization only makes sense if you are using a cross-toolchain (with its own copy of sysroot). It is not needed when building directly on the device.

    in reply to: VS 2026 #36998
    support
    Keymaster

    Hi,

    Please make sure you are using the latest VisualGDB 6.1 and not the older version. Depending on your VS installation mode, you may need to uninstall the older VisualGDB first.

    in reply to: Use existing RPi OS? #36990
    support
    Keymaster

    Looks like you are still trying to use our toolchain that will not work with your target OS. Please try configuring VisualGDB to build the projects directly on the device instead.

Viewing 15 posts - 16 through 30 (of 7,900 total)