[support]

You are welcome. Feel free to get back to us if you have any further questions.

[support]

Hi,

Most likely this happens because GhostDoc checks for the regular VC++ source file type (“C/C++”) while VisualGDB uses a different name for files handled by Clang IntelliSense (“C/C++ (VisualGDB)”). Please consider relaying this to submain – they should be able to extend their product to recognize VisualGDB’s C++ files fairly easily.

[support]

Hi,

Thanks for the update. In order to resolve the problem, it needs to be narrowed down to a specific set of circumstances that trigger it. Based on your description, it might be caused by the “gnu++17” flag (Clang would normally use gnu++1z, not gnu++17), although it might be caused by something else.

In order to narrow it down, please try to reproduce the problem on a cleanly created “Hello, World” project (e.g. by adding #include<> statements or properties similar to the ones in your project) and then describe the exact steps that trigger the problem (i.e. all choices made in the wizard and all settings and code added to the project since it was created). Based on that, we should be able to see what is going wrong and suggest the combination of settings that will work.

[support]

Hi,

This might be caused by corrupt Cygwin environment. Unfortunately the Cygwin binaries are not backward compatible, so installing newer versions of some libraries or tools in an environment with old cygwin1.dll (or tools built against the old cygwin1.dll) would render the entire environment unusable.

Please try installing a clean Cygwin environment from scratch – this should get it to work.

[support]

Hi,

No problem. Turns out the Espressif’s OpenOCD port was inadvertently resuming the target when starting the semihosting client, preventing gdb from handling the breakpoints properly. We have patched it and released an updated toolchain. Please update to R15.

[support]

Hi,

No problem. We have fixed the issues you described in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.7.2482.msi.

We should be able to support showing the contents of <p> with a monospace font after we switch our tooltip mechanism to a newer API, once we drop support for VS2008, however unfortunately we cannot give any time estimates on that.

[support]

Hi,

No problem, we can help you.

It looks like you might be using the old-style VisualGDB projects (e.g. GNU Make-based) that have to store various cached information (e.g. cached include paths) in the VC++ project files (hence, causing inconvenience with sharing the settings). If this is the case, would it be an option for you to upgrade to CMake?

The VisualGDB’s advanced CMake Project Subsystem provides much better experience – it will dynamically compute the cached file paths (and refresh when if needed) and won’t store any non-portable settings in the project file. It will automatically edit CMakeLists.txt files for you, so you won’t need to spend time getting used to the CMake syntax. You can get a quick overview of this subsystem here. If also lets you to debug the CMake scripts themselves, so you can diagnose settings-related problems faster than with GNU Make.

If this is not an option, please let us know which VisualGDB version you are using. v5.3 and later should automatically use the $(LOCALAPPDATA) syntax instead of relative paths.

[support]

Hi,

Strange. Just to recheck, could you please confirm that the following observations are correct:

1. When creating a new project with the VisualGDB Linux Project Wizard and using Clang IntelliSense, you still get the “missing <vector>” error.
2. The vector file is physically present in %LOCALAPPDATA%\VisualGDB\RemoteSourceCache\192.168.0.138\0000\include\c++\8\vector.
3. The %LOCALAPPDATA%\VisualGDB\RemoteSourceCache\192.168.0.138\0000\include\c++\8 directory is mentioned on the IntelliSense Directories page of VisualGDB Project Properties.

If yes, please open View->Clang IntelliSense Diagnostics Console and switch it to Project view. Click on your project and copy the CFLAGS/CXXFLAGS for it to clipboard. Please then post:

1. The screenshot of the entire VS window showing the “missing <vector>” error for the created “Hello, World” project.
2. The screenshot of the IntelliSense Directories page for the created “Hello, World” project
3. The CFLAGS captured from Clang IntelliSense Diagnostics Console
4. Any error messages shown in the log view of Clang IntelliSense Diagnostics Console

 

[support]

Hi,

Just wanted to share an update that we have released a new R14 build of the ESP32 toolchain based on the latest MSYS2 environment from Espressif and it looks like the Master checkout of the ESP-IDF now works out-of-the-box. Please feel free to install the updated toolchain via VisualGDB Package Manager.

[support]

Hi,

Good to know it works. Don’t hesitate to get back to us if you run into any further problems.

[support]

Hi,

Sorry, our regular license only includes email/forum support, but we should be able to help you narrow this down.

Please try closing VS, renaming the %LOCALAPPDATA%\VisualGDB\RemoteSourceCache directory and creating a new project using the VisualGDB Project Wizard.

This should re-download all the necessary files and get IntelliSense to work again.

[support]

Hi,

No problem, we will try to clarify. VisualGDB relies on many different 3rd-party tools to handle low-level device access, FLASH programming, etc. The most popular tools for ARM devices are:

• OpenOCD. It’s completely free and actively maintained (e.g. support for ST devices is contributed by ST itself), but may be sometimes buggy or require complex setup.
• Segger J-Link. It is normally designed to be used with the Segger J-Link Pro and other Segger debug probes. The J-Link hardware is more expensive than ST-Link, as Segger maintains a fully supported replacement to OpenOCD that works out-of-the-box with many devices, supports FLASH breakpoints, etc. They also provide functionally limited versions of it that could be FLASHed into ST-Link, but they are normally not covered by their support.

VisualGDB works with both underlying tools, so you can choose one depending on your preferences.

The issue you encountered with Segger software is likely caused by a missing driver, but it’s hard to say for sure. Generally, if you prefer something that works 100% of the time and is fully supported, please consider getting a J-Link Pro.

Alternatively, please try making a copy of your linker script (via VisualGDB Project Properties) and adding the following line before the end of each section:

. = ALIGN(64);

This will align each section to the 64-byte boundary and might solve the problem with the FLASH programming.

 

 

[support]

Hi,

Thanks for reporting this. Looks like a bug of the preview build. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.7.2478.msi

[support]

Hi,

Yes, we have tested our CMake fork on Cygwin. We used the following steps to build it:

1. Install the regular old CMake via the Cygwin package manager. It makes configuration easier as CMake doesn’t need to build a simplified version of itself in order to process its own CMakeLists.txt files.
2. Attempt the regular configuration (mkdir build && cd build && cmake ..). This will report a few missing libraries that can easily be installed via the Cygwin installer. In our tests, the libraries were libncurses-devel and libuuid-devel. You may want to try out the apt-cyg tool to install Cygwin packages from command line.
3. Run “make -j <CPU count> && make install”. That should be it. Ensure that VisualGDB uses the /usr/local/bin/cmake, not /bin/cmake and you are good to go.

[support]

Hi,

Yes, please try installing VisualGDB 5.4 Preview 7 and get the latest version of the GoogleTest framework via the VisualGDB Package Manager. It does include GoogleMock.

[Author]

Posts