Forum Replies Created
-
Posts
-
Hi,
No problem.
@maras: The easiest way to split the project would be to copy the .vcxproj file, replace the project GUID in the copied one, add the second project to the solution, switch its type to static library (via VS Project Properties), reference it from the main project. Then make a copy of both .vcxproj files and do the actual splitting – remove roughly a half of the sources from the first project and remove the remaining sources from the second one. If the same problem reoccurs, please restore the backup copies and try a different split (e.g. only the file with main() in the main project and the rest of the source files in the other project). Let us know if you run into any issues with it and we will help.
@phildimond: Thanks for sharing your concerns. We will try to clarify this and help you find the best solution. VisualGDB itself doesn’t provide a “platform” – instead it provides a common set of development/debugging tools that work on many 3rd-party frameworks (e.g. STM32Cube, NXP McuXPresso, ESP-IDF, Arduino, mbed, …). Not sure what you meant by going back to the manufacturer’s platform – the VisualGDB projects are usually based on the manufacturer’s platforms.
VisualGDB can also be easily configured to build/debug projects with any other framework – simply import it as an external project and you will be able to use the debugger (immediately) and IntelliSense (after configuring include directories). You can use this approach to import a project built with either mbed-cli or PlatformIO and still develop/debug it with VisualGDB. The only difference compared to the upcoming advanced mbed subsystem is that you will have to tell VisualGDB the command line to build the project, configure IntelliSense directories and edit the configuration scripts manually when you need to make changes to your project (the advanced mbed subsystem will provide GUI for common configuration settings). This is fully covered by our tech support, so feel free to create another thread sharing any issues you encounter and we will walk you through getting it to work.
As for the PlatformIO IDE, it is built on top of the Electron platform (i.e. is essentially a Web App running inside a separate browser instance). This makes it truly cross-platform, however it also inherits all the drawbacks of browser-powered applications like slow performance and complications making large-scale GUI. VisualGDB is built on top of a different technology, so it features much more detailed code analysis logic, works much faster and provides convenient and detailed GUI for common scenarios, regardless of the underlying platform you choose.
Hope this explains. Let us know if you have any further questions and we will be happy to help.
Hi,
Sorry about that, it should indeed be ItemGroup. When placed inside a target, it will work the same as ItemDefinitionGroup works normally.
Good to know it works and let us know if you encounter any further issues.
Hi,
Please try updating to VisualGDB 5.4 Preview 7 if you are not using it yet. It will ask whether you want to inherit the project settings from the startup project when you attach to your executable.
Another option would be to select “Attach” in VisualGDB Project Properties -> Debug Settings and use the regular F5 shortcut to start debugging.
Both options will honor the extra gdb commands added via VisualGDB Project Properties and custom path mappings.
You can use the regular VC++ (non-Clang) IntelliSense on imported projects as well, although using Clang IntelliSense makes it easier (e.g. it can search for missing headers and automatically insert the missing directories into project properties).
The virtual folder bug looks like something that was fixed in v5.4. Please let us know if you can still reproduce the problem after updating to this version.
Hi,
Sorry for the confusion. Indeed several internals of OpenCV have changed since we published the tutorial.
We have updated the tutorial to reflect the latest OpenCV version, and also added a few usability improvements to VisualGDB (like automatic deployment of the binaries installed by CMake). Please try this build and follow the updated tutorial from the beginning. It should be much easier now.
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:
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.
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?
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.
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).
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.
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.
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.
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.
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).
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.
