[support]

Hi,

No problem, we will help you resolve it. VisualGDB 5.4 imports the custom toolchain by creating folder under %LOCALAPPDATA%\VisualGDB\ToolchainProfiles\localhost. Please double-check that a folder corresponding to your toolchain has been created and that it either contains a Toolchain.xml/CustomToolchain.xml file, or points to the toolchain directory via a ToolchainLink.txt file (in the latter case the toolchain directory itself should contain the XML file).

Then check the XML file for the toolchain type (i.e. that it’s set to “Linux”). You can also get a detailed debug log of the toolchain enumeration logic by enabling View->Other Windows->VisualGDB Diagnostics Console and then opening VisualGDB Package Manager (this will reload the toolchain list).

If nothing helps, please attach:

• The relevant screenshot showing no toolchain in v5.4
• The diagnostic log mentioned above
• Your Toolchain.xml or CustomToolchain.xml file and let us know where it was located (under %LOCALAPPDATA% or in the toolchain directory).

This should help us narrow it down and suggest a working solution.

[support]

Hi,

Most of the VisualGDB’s settings are stored in registry under HKEY_CURRENT_USER\Software\Sysprogs\VisualGDB\Settings, so you can delete the subkeys of this key (don’t delete the key itself, as it would break the license-related logic and make VisualGDB unusable on that machine).

The only subset of settings not affected by this is Tools->Options->Text Editor->C/C++ (VisualGDB)->General/Scroll Bars/Tabs as those settings are managed by Visual Studio itself. The easiest way to reset those 3 tabs is to simply copy the values from any other language (e.g. regular C/C++).

[support]

Hi,

Yes, converting large projects could be a non-trivial endeavor, but it might save time long-term due to better integration with VisualGDB’s features. Ultimately we can help you get it to work with any project type you choose, just wanted to ensure you are aware of the advantages of the new CMake Project Subsystem.

As long as you are using VisualGDB 5.3 or later, please try modifying anything on the Makefile Settings page of VisualGDB and click “Apply”. VisualGDB should retest the toolchain and save the include paths using the $(LOCALAPPDATA) syntax.

[support]

Hi,

This looks like an issue that is already resolved in VisualGDB 5.4. Please try installing the latest VisualGDB 5.4 Preview 7 and let us know if the problem persists.

P.S. No worries about the link, we have edited your original post to show the correct URL.

[support]

Hi,

On the ESP32 platform, the semihosting client is actually a part of the Espressif’s OpenOCD port. VisualGDB starts it using the “monitor esp32 apptrace start” command and then forwards the output to the output window. The exact low-level logic of it is unfortunately outside VisualGDB’s control.

The best way to get it to work would be to narrow down a specific sequence of steps that reproduces the problem (e.g. certain program, certain breakpoint locations), reproduce it by manually running the “monitor esp32 apptrace start” command via the GDB Session window and forward the details to Espressif. As they have a more detailed knowledge of their tools’ internals, they might be able to tell what is going on.

[support]

Hi,

Thanks for the update. We have managed to reproduce the problem. It looks like the Unix domain socket support is broken in the latest Cygwin.

We should be able to work around it by switching the Cygwin CMake to use regular TCP/IP sockets instead. Please allow 5-10 business days for us to fix it.

[support]

Hi,

Good to know it works. Feel free to let us know the details about your project requested before and we should be able to patch VisualGDB to use the correct setting automatically (as long as we can reproduce this on our side).

[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

 

[Author]

Posts