[support]

Hi,

The easiest way to resolve this would be to manually add a statement filtering out the excluded files to Makefile (using the $(filter–out …) syntax).

Another option would be to patch the VisualGDB MSBuild platform files to run your compiler instead of the gcc. If the Intel compiler command line is compatible with the gcc command line, we can add an option to override the gcc executable via Project Properties. If not, you would need to create a file similar to gcc.xml (in VisualGDB directory) describing the command-line options for the Intel compiler. Let us know if you would like to try this out and we will provide you with a build that allows overriding the compiler name.

[support]

Hi,

Sorry, getting a toolchain right is often tricky, that’s why we provide it as a paid service. The good news is that 64-bit ARM boards are becoming more mainstream (Raspberry Pi 3 is actually 64-bit, although the Raspbian distro is 32-bit), so we may eventually add a free 64-bit cross-toolchain if one of the boards becomes really popular.

[support]

Hi,

This likely happens because those extensions are specifically looking for the regular Visual C++ project backend. If you are using Clang IntelliSense, it completely replaces the regular C++ IntelliSense, so extensions that are not aware of the Clang IntelliSense won’t find it.

You could disable Clang IntelliSense via VisualGDB Project Properties (or via a switch on the Clang IntelliSense Diagnostics Console window), however this would reduce the quality of the code completion results, as the Clang IntelliSense is specifically designed to work the best with GCC-specific code.

[support]

Hi,

Thanks for the dump file. It looks like it might be related to a recently solved problem. Could you please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.3.18.2019.msi

If the problem persists, please attach an updated dump file so that we could investigate it.

[support]

Hi,

This looks like a missing (or incorrectly configured) test framework directory. Normally, VisualGDB would reference the test framework files as shown below:

LOCAL_SRC_FILES := $(TESTFW_BASE)/com.sysprogs.unittest.googletest/src/gtest-death-test.cc <...>

Then it would pass the TESTFW_BASE variable via environment. Could you please check whether the LOCAL_SRC_FILES statement uses this syntax? If yes, does setting TESTFW_BASE to $(LOCALAPPDATA)\VisualGDB\TestFrameworks solve the problem?

[support]

Hi,

The normal ARM cross-toolchain only works for barebone devices (i.e. without Linux). If you would like to target Linux, you would need a special toolchain that is built to match your Linux distro and configuration. Please check your device vendor’s site whether they provide such a toolchain. If not, we could build one for you as a part of our custom toolchain building service. Please contact our sales if you would like to get a quote.

[support]

Hi,

VisualGDB would normally use the HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss\DefaultDistribution registry key to locate the LXSS distro to use. Could you please check that the value points to a valid LXSS installation on your machine? If you are not sure, please feel free to attach a screenshot of that registry key contents (or a .reg file).

As another quick workaround please try creating another regular SSH connection and simply specify localhost:<port number> in the “Host name” field, so that VisualGDB will use SSH.

[support]

Hi,

Normally this should not be a problem, however if your code depends on some specific constraints of the ARM GNU Toolchain, simply using it instead of the toolchain installed by VisualGDB should be the easiest solution.

[support]

Hi,

This will disable renaming triggered by editing the code. You will be still able to rename the functions and variables via Edit->Refactor->Rename (or by pressing Ctrl-R, R).

[support]

Hi,

If you are using a cross-toolchain (that implies using gdbserver), your program’s output will be displayed in the gdbserver window. VisualGDB includes a terminal emulator, so if your program is using the common ANSI escape sequences, VisualGDB will be able to handle them properly.

If it looks like the terminal emulation is not working, please let us know the details and we will look into this.

[support]

Hi,

Thanks for the update. The toolchain shipped with VisualGDB indeed uses a slightly different naming scheme, however should be able to locate the correct libraries as long as you specify the ARM core and the floating point mode. Either way, if switching to the original ARM toolchain solves the problem, VisualGDB fully supports it, so we would recommend simply keeping that toolchain.

[support]

Hi,

Good to know it works. If you encounter further problems, feel free to let us know and we will help.

[support]

Hi,

You can use the Call Stack window to see the code that triggered the hard fault (unless the stack got corrupt or the stack pointer is set incorrectly). In the latter case please try simply putting a breakpoint in Reset_Handler and stepping through the initialization code to discover the line triggering the hard fault.

[support]

Hi,

This could have been caused by the updated toolchain engine that does automatically finds the toolchain during build instead of hardcoding its location in the project properties. Some manual modifications to the project files that previously worked with v5.1 and v5.2 would not work with v5.3 due to this update.

Either way, feel free to let us know more the details of the error you get and we can help you get v5.3 to work.

[support]

Hi,

If you are using MSBuild, the map file should already be created in the same directory as the ELF file. You can also override it via the Linker Settings -> Advanced (e.g. to $(OutDir)file.map).

Based on our quick research, the -save-temps option always saves the temporary files in the current directory (VisualGDB sets this to the project directory so that relative paths specified in project properties would work as expected). The only way we could suggest to override it would be to add a custom post-build step that would move the generated files to $(OutDir).

Regarding the ELF files, we would advise diagnosing it as follows:

• Dump build command lines from both Eclipse and VisualGDB. E.g. using procmon. If you are using MSBuild, VisualGDB stores all command lines in the .rsp files, so you can simply reuse them.
• Build the project manually using both command line sets. Ensure that the ELF files still produce different results.
• Try linking the files compiled using the Eclipse command lines using the VisualGDB linker command line. This should tell if the problem is related to the linker or the compiler.
• If the problem is linker-related, compare the link command lines and try removing half of the differences to see if this fixes the problem. Repeating this a few times should help pinpoint the setting responsible for the error.
• If the problem is compiler-related, use a similar approach to pinpoint the source file causing the problem and then the command line argument causing it.

Unfortunately this does involve non-trivial amount of troubleshooting, however given the size/complexity of the project, it could be easier than trying to guess the offending setting otherwise.

[Author]

Posts