[support]

Hi,

We had actually done a detailed investigation on this issue could reproduce the problem by running gcc manually (and passing it a long list of .o files via an .rsp file). The difference comes from the fact that mbed first builds several static libraries (with less object files per library) and then links them together into the final ELF file. This results in less object files per command line than with VisualGDB, and hence doesn’t trigger the problem.

You can work around it by creating a similar project structure under VisualGDB – main executable + libraries.

We have also received increasing amount of feature requests for improving mbed support, so we might be able to support the advanced mbed project subsystem (similar to the advanced ESP-IDF project subsystem) in v5.4, although we won’t promise this 100% yet.

As for PlatformIO, it’s a higher-level framework that focuses on easy portability with a basic set of tools, while VisualGDB focuses on providing advanced debugging and code analysis/navigation functionality for larger projects that are not limited to any specific framework. Depending on your project requirements, either approach may work, but if you are planning to do non-trivial debugging or explore large 3rd-party code bases, you may find the features provided by VisualGDB worthwhile.

E.g. check out the new CodeJumps feature added to the upcoming Preview 8 (you can try out an experimental build with it here: http://sysprogs.com/files/tmp/VisualGDB-5.4.7.2499.msi) that can instantly visualize relations between different parts of your code:

Attachments:

You must be logged in to view attached files.

[support]

Hi,

No problem. Although this is not officially supported (i.e. may not work in some circumstances/may require inconvenient custom setup), you should be able to achieve this.

In order to use VisualGDB without VisualStudio (MSBuild only), please copy its directory (from Program Files (x86)\Sysprogs) to an arbitrary location on the server, then run VisualGDB.exe /about to register it. Then set %VISUALGDB_DIR% to point to the VisualGDB location and register the “VisualGDB” platform with MSBuild by copying the contents of the <MSBuild Platforms>\VisualGDB folder from a machine with Visual Studio.

As long as MSBuild can find the VisualGDB platform and the platform files can find VisualGDB itself (via %VISUALGDB_DIR), you should be able to build your projects even if VS is not installed.

If you encounter any difficulties, please let us know and we will help you get it to work.

[support]

Hi,

Do you mean that you would like to see the percentage of each section that is occupied by the actual symbols vs. padding at the end of the section?

[support]

Hi,

If the PreprocessorDefinitions macro gets resolved before the custom tool has a chance to run, please consider a slightly different approach. Remove the reference to your variable from the regular PreprocessorDefinitions and add the following code inside your <Target> element after the invocation of the custom tool (please update it to reference the actual variables):

<ItemDefinitionGroup>
 <ClCompile>
 <PreprocessorDefinitions>%(ClCompile.PreprocessorDefinitions);$(...)</PreprocessorDefinitions>
 </ClCompile>
</ItemDefinitionGroup>

As long as the code above is inside the “target” element, it will get evaluated after the tool is invoked and hence the variables will be resolved properly.

[support]

Hi,

Yes, the fix will be included. We currently plan to release another preview of v5.4 introducing a feature similar to CodeLens this week, then the first beta in another 1-2 weeks followed by a stable version in a few weeks more (depending on the feedback on Beta).

[support]

Hi,

VisualGDB 4.3 is very old and likely contains many bugs that have been fixed in later versions. Please consider updating to VisualGDB 5.4 Preview 7.

[support]

Hi,

Please double-check that your project is ARM-based and then check the Embedded Debug Tweaking page of VisualGDB Project Properties for the “ARM Semihosting” section. If it’s not shown, please attach  screenshots of the Embedded Debug Tweaking and MSBuild/Makefile Settings pages.

[support]

Hi,

The “cannot access a disposed object” error looks like a known VS bug. Please try installing the latest VS updated (not VisualGDB, but VS itself).

The wizard window looks like the VS theme was not loaded properly and VisualGDB could not get the correct colors. Reinstalling VisualGDB should normally help as it would trigger cache rebuilding. If not, please let us know which VS version you are using and also attach a screenshot of the main VS window and the “new project” window so we could see what parts of the theme are not loaded.

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

 

[Author]

Posts