[support]

Hi,

Good to know it works. If you encounter any further problems, don’t hesitate to contact us again.

[support]

Hi,

If you are using the Advanced CMake Project Subsystem, CMake directly reports a detailed project structure to VisualGDB, so as long as CMake can handle it, VisualGDB will work with it as well.

[support]

Hi,

We didn’t publish a detailed tutorial for the FX3 device as it’s not as mainstream as others (e.g. STM32), but we can easily share the details of the setup we used with Analyzer2Go.

We created a custom MSBuild-based project with manually imported sources and the linker script from the SDK. The debug process was relatively flaky through: Cypress provides a custom port of OpenOCD for the board, that unfortunately does not work very reliably. The setup that sort of worked for us was to program the FLASH memory using the Cypress tool, then launch their OpenOCD build (in the “custom gdb stub” mode) and connect gdb to it without reprogramming the FLASH memory.

If you are planning to use CMake, you can simply import your existing CMake project using the Embedded Project Wizard and then configure debug settings as described above.

Hope this helps. Let us know if you have any questions.

[support]

Hi,

We have released the updated VisualGDB 5.4 Preview 4 and the ESP32 toolchain (R10). Please try installing both updates and let us know if the problem is solved.

[support]

Hi,

Thanks for checking this. We should be able to help you resolve this if you could attach the output from the VisualGDB Diagnostics Console showing all command lines it launches and the corresponding output from valgrind.

[support]

Hi,

Thanks for mentioning that the project was upgraded from a Make-based one. This happens because GNU Make configurations require explicitly including the VisualGDB platform file, while the MSBuild configurations handle it automatically.

Although the message can be safely ignored, if you find it annoying, you can fix it by removing the following lines from your .vcxproj file:

 <ImportGroup Label="VisualGDBFindComponents">
 <Import Project="$(LOCALAPPDATA)\VisualGDB\FindComponents.props" />
 </ImportGroup>

Please note that it will break non-MSBuild configurations for the project, so we recommend removing them as well.

[support]

Hi,

If you are using the VisualGDB MSBuild backend, you can see why the linker is invoked by enabling verbose output:

Tools->Options->Projects and Solutions->Build and Run->MSBuild build output verbosity -> Detailed.

Then build the project and check for the “Re-linking <…> due to <…> message”. If you are not sure, simply attach the detailed build log here and we can help you understand it.

[support]

Hi,

You might be able to use the “adb connect” command (e.g. see our VirtualBox tutorial), however it might not work on your device, or might work unreliably.

[support]

Hi,

Yes, this is by design. The trial lets you evaluate all VisualGDB features and is hence equivalent to the Ultimate edition.

[support]

Hi,

If it is an external project managed by an external Makefile, the linker is likely re-invoked because the Makefile doesn’t handle dependencies properly.

You could try re-creating the project as an MSBuild-based project to let VisualGDB handle dependencies, although it might be non-trivial if the project has complex build settings.

[support]

Hi,

Thanks for reporting this. We have fixed it internally and will include it in the upcoming Preview 4.

[support]

Hi,

We would advise running a few quick experiments to understand what components could be causing this:

• Try profiling a “hello, world” program with VisualGDB.
• If it doesn’t work, try running valgrind manually (let us know if you need help with command lines).
• It the “hello, world” works, try running valgrind manually with your program.

If it looks like the problem is between valgrind and your specific project, please try simplifying it (e.g. removing some sources/libraries/optimization settings). If the problem occurs with VisualGDB, but doesn’t occur otherwise, it’s likely caused by some arguments VisualGDB is using. In this case please try comparing the command lines that work and the command lines used by VisualGDB (from View->Other->VisualGDB Diagnostics Console).

If you need further help at any step, don’t hesitate to get back to us.

[support]

Hi,

Most likely you are trying to use some of the features that are only available in the Custom edition.

You can find a detailed overview of VisualGDB features and different editions here: http://visualgdb.com/buy/

If you believe the message is shown by a mistake, please let us know the exact steps that lead to the message.

[support]

Hi,

The MSBuild projects define a GUI option for the debug information format (C/C++ -> General -> Debug Information Format), so specifying it via command line would result in 2 different settings passed via the command line. Please instead change the corresponding GUI setting. If the value you are trying to add is not shown in the dropdown list, simply enter the corresponding flag (e.g. -gdwarf-5) in the field directly.

[support]

Hi,

This might be caused by CMake itself caching some old settings. In that case doing a full rebuild should help.

If it doesn’t, please provide the exact steps to reproduce it and we should be able to fix it promptly.

[Author]

Posts