[support]

Hi,

OK, this looks like a different error and should be very easy to fix. Please click the ‘repair’ link at the bottom of the MSBuild Settings page shown on your screenshot and VisualGDB will repair everything automatically.

With code analysis, the Clang engine could be disabled globally or may have troubles attaching to the project. Please check the View->Clang IntelliSense Diagnostics Console for initialization-related messages (e.g. close the solution, clear the console log and re-open it). If you are not sure, simply post the log here and we will help you understand what is going on.

[support]

Hi,

This looks like a buggy gdb build or some incompatibility between gdb and the debug information format. Were you able to debug your programs on that machine successfully before? If yes, we would advise trying to revert to the gdb version that worked.

Another option would be to check if the gdb hang is related to the debugged binary (e.g. does it hang with no debugged binary or with a simple “hello, world” program?). If yes, changing the debug information format (e.g. -gdwarf-2) might solve this. If the program consists of many large shared libraries, stripping the ones you don’t want to debug (using the ‘strip’ command) will reduce the amount of symbols loaded in gdb and could also improve performance.

Yet another option would be to try running gdb on the Windows side instead (note to other readers: this requires the Custom edition). With VisualGDB 5.3 it’s as easy as selecting “allow changing build/debug command host” on the first page of VisualGDB Project Properties, adding an action to download the built binary on Windows and then changing “gdb executable” on the Debug Settings page to your Windows gdb.exe (it needs to match the Linux target type). VisualGDB will then figure out how to use gdbserver and update the startup commands automatically.

[support]

Hi,

You can activate VisualGDB on the build server by running “VisualGDB.exe /about”. This will show the “About VisualGDB” window and let you enter the key.

If this does not work, please update to VisualGDB 5.3.

[support]

Hi,

Please find the answers to your questions below:

1. We indeed don’t support DA14580 yet. As a workaround please consider selecting “Specify flags manually” in the wizard and manually adding include directories/preprocessor macros specific for the device as shown in our legacy device tutorial. It also looks like the DA14580 popularity is raising over time, so we may add direct support for it later once we see enough interest for it. We also offer a service of creating BSPs for non-mainstream devices. Feel free to contact our sales if you need a quote.
2. VisualGDB provides an equivalent of the “-preinclude” command option via the “Forced Includes” option as shown below:

If you have any further questions, feel free to let us know and we will help you.

Attachments:

You must be logged in to view attached files.

[support]

Hi,

We have just added support for this to the final VisualGDB 5.3 (MSBuild projects only). Simply use the VS project properties (not VisualGDB Project Properties) to add the system include directories to your project.

[support]

Hi,

Looks like we missed it with our built-in visualizers. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.11.1837.msi

[support]

Hi,

Older version of CMake could have contributed to this indeed. Either way, if you run into this again, feel free to let us know more details and we will help you troubleshoot this.

[support]

Hi,

Thanks, the toolchain references look correct. Could you please try attaching the screenshot of the error along with the %LOCALAPPDATA%\VisualGDB\FindToolchain.props file? This should show what exactly is VisualGDB looking for and what toolchains are installed.

[support]

Hi,

Thanks for verifying your support status.

It looks like the gdb executable is either hanging while VisualGDB is trying to execute initial commands, or the communication between VisualGDB and gdb is broken.

Please try enabling the gdb logging via VisualGDB Project Properties -> Advanced GDB Settings, then reproduce the problem, cancel the session and view the gdb log.

Do you see just one ‘-data-evaluate-expression’ command or multiple commands sent rapidly? If it is just one command, please try running gdb manually using the command line shown in the log and re-running the same commands. Does this trigger the gdb hang?

[support]

Hi,

Please use the VisualGDB Project Properties to synchronize the toolchain sysroot.

[support]

Hi,

Strange, com.visualgdbm.arm-eabi is a toolchain ID, not BSP ID. Could you have accidentally edited the project files manually and confused some settings? Either way, does creating new projects with the toolchain/BSP work?

If yes, could you please compare the ToolchainID tags in the working vs. non-working projects (in .vgdbsettings files as described here)?

[support]

Hi,

Just to double-check, are you checking the “use the advanced CMake Project Subsystem” checkbox? If you are not sure, please try attaching a screenshot of the Solution Explorer in your project and we can check if this looks like the advanced CMake subsystem is active.

[support]

Hi,

This could be caused by some toolchains-specific or connection-specific issues. We can help you troubleshoot this if you could let us know the email associated with your license so that we could verify your support status.

[support]

OK, we have added support for running custom shortcuts in the background to the final release of VisualGDB 5.3.

[support]

OK, we have fixed the issue with uploading imported project contents on the first build in the final release of VisualGDB 5.3.

[Author]

Posts