[support]

Hi,

Please ensure you are using the latest VisualGDB 5.3R8. It includes special logic for handling this – if you run any command that output “Loaded symbols for <…>” via the GDB session window, it will automatically re-query and update the call stack.

[support]

Hi,

Normally you don’t need to specify anything manually if you use the new “Debug a crash dump” command. If you still get the error when using this command, please let us know.

[support]

Hi,

This looks like VisualGDB fails to initialize and the service configuration is preventing it from displaying the error message properly (likely due to missing per-user configuration files). Please try temporarily configuring the service as an interactive service so that you can see the VisualGDB error messages). Please also ensure you run VisualGDB from the same user account that you used to configure it (toolchain definitions and other settings are stored separately for each user).

[support]

Hi,

You do need to use the same target-specific gdb that you use for regular debugging. If you are using VisualGDB 5.3, you can actually open a core dump file by right-clicking on the project and selecting Debug->Debug a Crash Dump. This will automatically reuse the GDB and other settings from your project settings.

[support]

Hi,

Sorry, we didn’t mean to make it confusing. The lightning icon is actually a standard VS icon for events, so we reused it in VisualGDB.

You can also use the Debug->Exceptions menu (VisualGDB displays Linux signals there), although the VisualGDB-specific window provides more control over the way signals are handled.

[support]

Hi,

The ESP32 flashing is unfortunately indeed unreliable. It is provided by the Espressif’s ESP32 OpenOCD port, so we would advise double-checking with Espressif whether they have a hotfix for this.

We have rebuilt the OpenOCD executable using the latest patches from them here: http://sysprogs.com/files/tmp/openocd.exe;  feel free to try replacing the OpenOCD binary in the toolchain directory with it (we have not fully tested it yet).

The issue with the variables is caused by the optimization. Using any other optimization level than -O0 makes GCC optimize out some variables, however using -O0 to build ESP-IDF code results in crashes during startup. As a workaround please try setting the optimization level to -O0 for specific files you want to debug (via the regular MSBuild File Properties). This should keep the ESP-IDF framework in a usable state, while providing full debug functionality for your code.

If you encounter any further problems, feel free to contact us again and we will help you resolve them.

[support]

Hi,

GCC and Keil compilers are indeed not 100% compatible, so switching your project to a different compiler might require non-trivial adjustments. We only recommend using Keil with VisualGDB if you are trying to build existing Keil-specific code. For all other cases  we recommend using our GCC-based toolchain that is fully supported by all project types and works out-of-the-box.

[support]

Hi,

You can set the linker script via the MSBuild Settings page of VisualGDB Project Properties (the last setting on that page).

[support]

Hi,

Please use the “Signals & Exceptions” button in the GDB Session window. It allows overriding which of the signals are passed to the program.

Please note that disabling stops on SIGINT may stop breakpoints in your program from working, as they internally rely on catching this signal.

 

[support]

Hi,

Thanks for confirming this. Most likely the template was created from a stand-alone project and hence all projects created from this template will also be stand-alone.

You can turn semihosting off for stand-alone projects by manually editing the LDFLAGS, although the exact options to add or remove depend on the toolchain version you are using, although it might be non-trivial to find the right combination of flags. Normally we would advise re-creating the template from a non-standalone project. Then VisualGDB will let you conveniently change all settings via simple GUI menus for all projects created from this template (it will also automatically update the settings when you upgrade to a newer toolchain).

Also normally you don’t need to disable the semihosting – as long as your code doesn’t call printf() and other similar functions, the semihosting-related functionality will be automatically excluded from the project by the linker.

[support]

Hi,

Thanks for clarifying this. We have double-checked the advanced CMake projects with yocto-based toolchains and it indeed looks like VisualGDB might ignore the environment file for some of the tests.

Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.1.2062.msi

 

[support]

Hi,

Thanks for clarifying this. The project structure of the VS cross-platform projects is different from the Win32 projects, so simply adding the VisualGDB platform to them would unfortunately produce unpredictable results.

We would advise importing the project using the VisualGDB project wizard. This will re-create the project file with all the necessary constructs and will discover and add the source files from the project directory.

[support]

Hi,

Sorry for the confusion. If you want to be able to easily migrate between the toolchains and BSP versions, please don’t convert your projects to stand-alone ones. The regular VisualGDB projects don’t hardcode any toolchain-specific (or BSP-specific) flags, so you can easily switch BSPs, toolchains, FP modes and other settings for them. The stand-alone projects are specifically designed for the case where you don’t want to rely on VisualGDB to manage your settings and want to be able to tweak them manually.

If you used the stand-alone projects due to a different reason, please feel free to share your constraints and we will try to suggest a better way of satisfying them without losing the convenience of the regular non-stand-alone projects.

[support]

Hi,

Thanks for confirming this. Then it looks like the project file itself is missing some of the elements the normal .vcxproj files should have. The easiest way to pinpoint this would be to use a diffing tool (e.g. KDiff3) to compare the 2 .vcxproj files side-by-side and try editing one of them to make it as close as possible to the other one. Once you encounter the step that causes this problem, you should be able to revert it on the other project to fix it.

[support]

Hi,

Strange. Could you please try creating a new MSBuild-based VisualGDB Linux project from scratch and confirm that the problem still persists? If yes, what are the contents of the C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\VC\VCTargets\Platforms\VisualGDB folder?

[Author]

Posts