[support]

Hi,

Thanks, we have located and fixed the problem. It was caused by a conflict between an internal target called ‘build’ and build.c in your project. Please try this build: VisualGDB-5.2.12.1269.msi

[support]

OK, we have added support for this to VisualGDB 5.2 Beta 4.

You can find a detailed tutorial here: http://visualgdb.com/tutorials/linux/win10/

[support]

Hi,

No problem. Could you provide an example of the copy-modify-writeback function you mentioned? Do you mean software breakpoints in FLASH memory?

[support]

Hi,

This looks like a known bug of Resharper. Please try disabling it and ensure that you have Visual C++ installed.

[support]

Hi,

Sorry, looks like you are using v5.1. Please try the latest v5.2 beta. It uses separate internal environments to handle the long reparse and critical operations like code completion, so it should be much faster.

[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

[Author]

Posts