[support]

Hi,

Thanks for sharing this. Indeed the target name should not collide with any of the existing targets, as it would override the original target. Setting $(BuildDependsOn) to include your target name should be the right thing to do.

If it doesn’t work, please try setting the MSBuild build log verbosity to “Diagnostic” via Tools->Options->Build and Run and then check that your target is being built, the task is being executed and returns the correct value and that it happens before the actual compilation phase.

[support]

Hi,

Please try opening View->Embedded Memory Explorer and keeping it open in the detailed view. It will automatically update each time you build the project, showing you the detailed per-section and per-symbol statistics (and also other useful information like offline disassembly or stack usage analysis).

[support]

Hi,

Sorry, we haven’t tested kgdboe with this kernel version yet. We will run the tests on it, patch it and update the version installed by VisualKernel in the next few months.

If the fix is trivial and you don’t want to wait for an official update from us, you can simply fork our Github repo, patch the code and replace the files in %LOCALAPPDATA%\VisualGDB\VisualKernel\KernelPackages\kgdboe.

[support]

Hi,

Thanks for sharing this. We have just finished rechecking everything with the latest OpenCV release and the latest Raspberry Pi toolchain and updated the tutorial.

We have also added a few usability features to VisualGDB (e.g. automatic deployment of installed CMake targets), so please use this build if you would like to try the new features.

[support]

Hi,

The text you attached doesn’t contain any specific error message, so the problem may not be on the OpenOCD’s side.

Please describe what exactly you are observing/expecting and also obtain and attach a gdb session log as described here so that we could see what is going on.

[support]

Hi,

We would advise using VisualGDB. It will automatically handle symlinks when synchronizing the sysroot and will also upload the directories correctly when building projects.

[support]

Hi,

If you are using MSBuild, you can script it by creating a custom MSBuild target (VisualGDB uses the same target system as regular MSBuild projects).

You can find extensive documentation on creating MSBuild tasks here: https://docs.microsoft.com/en-us/visualstudio/msbuild/task-writing?view=vs-2017

Also consider having a quick look through our version updating task used by our open-source plugins. You could create a similar C# task that would export an MSBuild variable and then reference this variable in the “Preprocessor Definitions” setting.

 

[support]

Hi,

No problem, we will help you resolve it. VisualGDB 5.4 imports the custom toolchain by creating folder under %LOCALAPPDATA%\VisualGDB\ToolchainProfiles\localhost. Please double-check that a folder corresponding to your toolchain has been created and that it either contains a Toolchain.xml/CustomToolchain.xml file, or points to the toolchain directory via a ToolchainLink.txt file (in the latter case the toolchain directory itself should contain the XML file).

Then check the XML file for the toolchain type (i.e. that it’s set to “Linux”). You can also get a detailed debug log of the toolchain enumeration logic by enabling View->Other Windows->VisualGDB Diagnostics Console and then opening VisualGDB Package Manager (this will reload the toolchain list).

If nothing helps, please attach:

• The relevant screenshot showing no toolchain in v5.4
• The diagnostic log mentioned above
• Your Toolchain.xml or CustomToolchain.xml file and let us know where it was located (under %LOCALAPPDATA% or in the toolchain directory).

This should help us narrow it down and suggest a working solution.

[support]

Hi,

Most of the VisualGDB’s settings are stored in registry under HKEY_CURRENT_USER\Software\Sysprogs\VisualGDB\Settings, so you can delete the subkeys of this key (don’t delete the key itself, as it would break the license-related logic and make VisualGDB unusable on that machine).

The only subset of settings not affected by this is Tools->Options->Text Editor->C/C++ (VisualGDB)->General/Scroll Bars/Tabs as those settings are managed by Visual Studio itself. The easiest way to reset those 3 tabs is to simply copy the values from any other language (e.g. regular C/C++).

[support]

Hi,

Yes, converting large projects could be a non-trivial endeavor, but it might save time long-term due to better integration with VisualGDB’s features. Ultimately we can help you get it to work with any project type you choose, just wanted to ensure you are aware of the advantages of the new CMake Project Subsystem.

As long as you are using VisualGDB 5.3 or later, please try modifying anything on the Makefile Settings page of VisualGDB and click “Apply”. VisualGDB should retest the toolchain and save the include paths using the $(LOCALAPPDATA) syntax.

[support]

Hi,

This looks like an issue that is already resolved in VisualGDB 5.4. Please try installing the latest VisualGDB 5.4 Preview 7 and let us know if the problem persists.

P.S. No worries about the link, we have edited your original post to show the correct URL.

[support]

Hi,

On the ESP32 platform, the semihosting client is actually a part of the Espressif’s OpenOCD port. VisualGDB starts it using the “monitor esp32 apptrace start” command and then forwards the output to the output window. The exact low-level logic of it is unfortunately outside VisualGDB’s control.

The best way to get it to work would be to narrow down a specific sequence of steps that reproduces the problem (e.g. certain program, certain breakpoint locations), reproduce it by manually running the “monitor esp32 apptrace start” command via the GDB Session window and forward the details to Espressif. As they have a more detailed knowledge of their tools’ internals, they might be able to tell what is going on.

[support]

Hi,

Thanks for the update. We have managed to reproduce the problem. It looks like the Unix domain socket support is broken in the latest Cygwin.

We should be able to work around it by switching the Cygwin CMake to use regular TCP/IP sockets instead. Please allow 5-10 business days for us to fix it.

[support]

Hi,

Good to know it works. Feel free to let us know the details about your project requested before and we should be able to patch VisualGDB to use the correct setting automatically (as long as we can reproduce this on our side).

[support]

You are welcome. Feel free to get back to us if you have any further questions.

[Author]

Posts