[support]

Hi,

If the bootloader expects the non-bootloader code to be placed at a specific address (e.g. 0x8005000), the easiest way to achieve this is to add a line like this before the corresponding section in your linker script:

. = <offset to place subsequent code/data>

You can double-check the addresses of the code and variables by enabling the map file generation and looking through the map file once the build is done.

[support]

Hi,

Sorry, not fully automatically yet. You can either re-create a project, or manually create a new platform “VisualGDB” via the Configuration manager and set the VS properties like .vgdbsettings file, toolchain, etc. manually. If you encounter any problems, feel free to let us know and we will provide help.

We will consider adding automatic conversion to v5.3.

[support]

Hi,

The easiest way would be to modify the Makefile to remove the references to EXTERNAL_LIBS so that the variable is simply ignored.

A better solution would be to try out the new MSBuild backend that comes with VisualGDB 5.2. It’s faster, more flexible and handles project references in a smarter way that does not break with non-default folder names.

[support]

Hi,

This is not possible directly, however you can simply remove the references to $(EXTERNAL_LIBS) in the Makefile rules. Hence VisualGDB will update the variable, but its value will be ignored.

[support]

Hi,

Sorry about this, it’s a separate problem actually. A quick workaround would be to manually change the colors for “Refactoring suggestion” via Tools->Options->Fonts and colors->Text Editor.

The upcoming Beta 4 will include automatic detection of the dark theme that will pick better default colors.

[support]

Hi,

The easiest way would be to copy it to the standard library directory on your target (e.g. /usr/lib), synchronize cross-toolchain sysroot (if you are using one) and just add the library name without the ‘lib’ prefix and ‘.so’ suffix to the “Library Names” field. Alternatively you could add the full path to the .so file to the “Additional Linker Inputs” field, but you would need to ensure that the relative path to the library during compilation matches the relative path during runtime (or use LD_LIBRARY_PATH to explicitly specify where to search for the libraries).

[support]

Hi,

Yes, please try selecting “Attach To -> Select -> Managed (v4.6, …) and Native”. Selecting both Managed and Native should catch the crash properly.

[support]

Hi,

No problem. We have added this to v5.3 roadmap and will post an update here once we have a preliminary version of the API available.

[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.

[Author]

Posts