[support]

Hi,

Thanks a lot for the log file. Normally VisualGDB optimizes the IntelliSense by pre-compiling a “preamble” – the part of the source file that only contains #include<> statements.

Looks like you are doing the following:

1. Editing the main source file
2. Switching to a header file that is a part of the preamble
3. Editing the header file
4. Switching back to the source file

This causes a full reparse of the main source file that is a very slow operation.

If you need to do that often, please try rearranging the #include<> statements in your main file as follows:

#include <rarely modified files>
static const int unused = 0; //or any other valid C/C++ statement
#include <frequently modified files>

This should force VisualGDB to not treat the frequently modified files as a part of the preamble.

You can double-check what is being reparsed in the Clang IntelliSense Diagnostics Console:

[+1:32:49.913] Found an outdated PSF 0 due to c:\users\manu.lange\source\ros_projects\rex_interface\include\rex_interface\rex_interface.hpp during initial check. It will be re-built.
[+1:32:49.928] Rebuilding PSF 0 (normal preamble)...

PSF 0 (normal preamble) refers to the preamble described above (combination of the #include<> statements from the top of the file). Normally VisualGDB should say that PSF (precompiled source fragment) 0 is up-to-date.

If this helps, please let us know and we will consider adding a mechanism for auto-detecting this and handling it automatically.

[support]

Hi,

OK, based on the extra details you provided in our support system we were able to pinpoint and fix this. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.12.1259.msi

[support]

Hi,

This looks like a resharper bug (see the Jetbrains frames in the stack). Please try contacting their support or disable it for the duration of the project creation.

[support]

Hi,

Sorry for the delayed reply. Yes, please try installing this build: http://sysprogs.com/files/tmp/VisualGDB-5.2.12.1259.msi

If the problem persists, please select ‘debug’, attach another instance of Visual Studio to the crashed one and check the call stack for the information about the exception location.

If you are able to track the exception, we should be able to fix it easily. If not, let us know the details you can gather and we will try to help you pinpoint this.

[support]

Hi,

Yes, sorry about the confusion. The tutorial assumes you are using Windows Desktop with Visual Studio to target Raspberry Pi running Debian (Jessie).

[support]

Hi,

Not fully sure how you managed to do that – if you select “select the toolchain by locating gdb.exe”, VisualGDB should handle the quotation marks properly. If you could clarify that, we would fix this behavior.

If you are not sure, try deleting the HKCU\Software\Sysprogs\VisualGDB\ThirdPartyToolchains key in registry – it contains the last used custom toolchains.

[support]

Hi,

This means that the problem happens when VisualGDB tries to parse the referenced project’s Makefile. Please try doing the same steps with it: re-create it from scratch and merge the changes one-by-one. Sorry about the inconvenience.

[support]

Hi,

Please try opening the VisualGDB Package Manager via the Tools menu and installing unit test frameworks from it.

Note that you will need an Internet connection on your VS machine and the firewall should allow VS to connect in order to automatically install the frameworks.

[support]

Hi,

Looks like your firmware also has the gdb stub enabled. The JTAG debugging and GDB stub debugging are mutually exclusive, so if you want to use JTAG, please simply disable the GDB stub in VisualGDB Project Properties.

The “download J-Link” option actually appears due to a bug – it only works with ARM targets. For JTAG debugging of ESP8266 we recommend using OpenOCD.

[support]

Hi,

Sorry, we don’t currently offer any special Arduino support. It is used by a relatively small fraction of our users and the effort to support importing it reliably would be huge, so we are currently focusing on other features.

We will continue monitoring the situation and will consider adding Arduino support if the situation changes.

[support]

Hi,

If you are using Makefiles, you need to edit them via the VisualGDB GUI (right-click on the project in Solution Explorer, select VisualGDB Project Properties). This will update IntelliSense accordingly.

If you prefer using your own Makefiles, you can add extra IntelliSense directories via the IntelliSense Settings page of VisualGDB Project Properties.

If you are new to VisualGDB, we would recommend trying v5.2 Beta 3 with the new MSBuild subsystem. It automatically synchronizes the build and IntelliSense settings and is generally more seamless than Make.

[support]

Hi,

You can try it at your own risk by following the instructions in this thread: https://sysprogs.com/w/forums/topic/esp8266-iram1_0_seg-too-large/

Please note that the ESP8266 SDK is largely undocumented and unreliable and doing this may trigger strange bugs.

[support]

Hi,

There are no functional limitations in the trial version. The VisualGDB MSBuild backend is relatively new, so this actually looks like a bug triggered by “..” in some of the paths.

Could you please send your .vcxproj, .filters, .vgdbsettings and .sln files to support@sysprogs.com? This should help us reproduce and fix this.

[support]

Hi,

Yes, we have investigated this. We will be adding a separate wizard option to create projects for the Win10 Linux subsystem in the final v5.2. We would expect to release it in the next 2-3 weeks.

[support]

Hi,

We would recommend generating a new project from scratch, ensuring that it does not have the problem and then comparing the Makefiles side-by-side and merging the differences step-by-step. This should help quickly understand what exact difference causes the problem.

[Author]

Posts