Forum Replies Created
-
Posts
-
Hi,
Most likely, you are using the Linux or Embedded license that does not support custom build steps (see this page for the full list of custom features).
You can find out the used edition via Help->About VisualGDB or upgrade it at this page.
You might be seeing the Custom edition GUI on other machines because the trial there has not expired yet (all VisualGDB features are unconditionally available during the trial period, even if a valid key has been entered).
Finally, you might be able to customize the build without the VisualGDB’s GUI by tweaking the Makefile, although using the Custom Steps GUI should be usually much more convenient.
Hi,
Version 5.3 is very old, so it indeed may not work as expected with the latest VS updates. Please try updating to VisualGDB 5.5 Preview 3 (you would need to renew you key here first).
Thanks, this partially explains what is going on. TryReadInstructions() is implemented inside VisualGDB. It uses the objdump tool to disassemble the instructions at the specified address.
Most likely, something in the objdump output is preventing VisualGDB from handling this correctly. Would you be able to share the ELF file with us via our support page so that we can try reproducing the issue (please also mention the exact address that is not loaded correctly and the function that triggers it)? If not, we can provide instructions on getting the necessary information from the dump file, although it might take a few extra iterations.
Hi,
The location of the project/solution files is normally handled by VS itself (see the checkbox next to the project name/location fields when creating the project).
Thankfully, VisualGDB has much more to offer than just a shortcut for launching make.exe 🙂
Either way, thanks for the log files. Looks like the new logic for analyzing linker messages was working slower than expected for long build command lines. We have optimized it in the following build: VisualGDB-5.5.3.3470.msi
No problem. Please try right-clicking on the project node in Solution Explorer and select Add->Reference->Browse, then pick the full path to VisualGDBExtensibility.dll in the VisualGDB’s directory. This should resolve the build errors.
Hi,
No problem, we have updated the sample project resolving this. Please update your local git checkout.
Hi,
The ARM toolchain only works with barebone targets. For more information on Linux cross-toolchains please see this page: http://visualgdb.com/hwsupport/linuxboards/
Hi,
You can disable VisualGDB updates via a checkbox at the bottom of the Manage VisualGDB Packages window. Also VisualGDB 5.5 Preview 3 allows disabling updates for a specific version of the package.
We understand that there is likely a bug in the new BSP, however we absolutely do not control the contents of the ST’s SDKs and it is absolutely not possible for us to provide free bugfixes to a major SDK maintained by a huge company, sorry. The best we could do is if you confirm that the problem exists with a freshly created VisualGDB project but does not exist when creating a similar project with the ST’s Eclipse-based IDE. If this is the case, we can help you find the difference between the 2 projects and update the VisualGDB project to replicate the other project’s results.
Hi,
Please refer to the following page for the instructions on downloading the old packages: http://visualgdb.com/support/oldpackages/
No problem. First of all, please try right-clicking on the function entries that did not get analyzed correctly and select “View Analysis Log”. This should highlight the code paths triggering various warnings.
You can then customize the analyzer by cloning the following project: https://github.com/sysprogs/VisualGDBExtensibilityExamples/tree/master/PlatformSpecificStackAnalyzers/ARM. Simply build the ARMStackUsageAnalyzer.dll file and copy it into <VisualGDB Directory>\StackAnalyzers, replacing the version shipped with VisualGDB. You can then use another Visual Studio instance to step through ARM-specific stack analysis logic or to modify it to support project-specific cases.
The Disassembly view would show the results once you select a specific function on top of the view.
Hi,
The most common cause of this issue would be another dialog window opening up in the background. Due to WinForms/WPF interop issues, dialog windows sometimes appear underneath the regular VS window and are hence not visible. Please check the task list (Alt-Tab) and the VS icon in the Task Manager to see if there are any extra dialog windows (e.g. confirming some missing tools).
If it doesn’t help, please try updating to VisualGDB 5.5 Preview 3 and let us know the exact project type you are creating (Embedded/Linux/etc; CMake/MSBuild/GNU Make) and also whether the problem triggers for other project types. Also please share a screenshot and a call stack or the frozen VS instance once it freezes for about 1 minute or more.
Hi,
Yes, please use the following setting: VS Project Properties -> General -> General -> Generate a test container file = Yes.
Note that this setting is stored separately for Debug/Release configurations, hence you need to update it for every relevant configuration.
Hi,
Based on the description you provided, everything should work. Hence the problem is likely caused by some small detail that was omitted from the description. Please share the screenshots of all the relevant settings (including the exact error message you get) and we will help you understand what is going on. If you do not wish to post them publicly, please consider sending them via our support form instead.
