[support]

Hi,

Sorry for the delay, we were working on an updated package for the ARM toolchain.

The “noreturn” warning comes from the way interrupt handlers are defined in the release build. VisualGDB provides default “weak” implementations redirecting to Default_Handler(), while the DefaultHandler() itself is declared as noreturn to save a few bytes on prologue/epilogue. The redirected handlers are not declared as noreturn because some of them will be replaced by the user-provided implementations that do return. This saves a few bytes on optimizing away the default handler, but does produce warnings in the full warning mode.

This logic has been in place for about 10 years, so we are somewhat hesitant to change it, as it may break someone else’s workarounds or fixes. If you can find a good way to suppress the warnings with pragmas, you can submit a pull request modifying this file. If it doesn’t change any functionalities, and just disables particular warnings, we can propagate it to the upcoming BSP versions.

With profiler framework, you can submit a pull request here.

As for overriding the warning level, if you are using MSBuild, you can change it on the file level (select the files in Solution Explorer, open properties and change the build flags for just these files). For Advanced CMake, the BSP/profiler go into separate CMake targets, so you can manually add CMake-level statements to your CMakeLists.txt that would alter the build options for just these targets.

Edit: thanks for the pull request, we have merged it. Just one thing, the new SignExtend() version was introducing an extra conditional branch, that is slower than just series of bitwise instructions, so we reverted it to a modified version of the original one, that should address the warnings.

• This reply was modified 3 months, 3 weeks ago by support. Reason: mentioned pull request

[support]

Hi,

You can find some documentation in the Wiki. But in general, the easiest way to get started would be to fork one of the existing BSP generators or debug package drivers, and use it as a reference to build your own one.

[support]

Hi,

Please refer to the MSBuild documentation on custom targets and properties. This is not specific to VisualGDB and we would advise getting familiar with the topic before doing any low-level customizations.

[support]

Hi,

This is by design. The toolbar always shows solution-level configurations, while the VisualGDB configurations are defined on the project level. Most likely, you somehow ended deleting the solution-level configurations and will need to recreate them via the Configuration Manager. See this page for more details.

[support]

Hi,

The rules for invoking the linker for the MSBuild projects are stored in the %VISUALGDB_DIR%\MSBuild\Targets\link.targets file:

<PropertyGroup Condition="'$(GCCBinaryNameForLinking)' == ''">
  <GCCBinaryNameForLinking>$(GCCBinaryName)</GCCBinaryNameForLinking>
</PropertyGroup>
<PropertyGroup Condition="'$(GXXBinaryNameForLinking)' == ''">
  <GXXBinaryNameForLinking>$(GXXBinaryName)</GXXBinaryNameForLinking>
</PropertyGroup>

<GCCLink 
  Sources="@(Link)" 
  CC="$(GCCBinaryNameForLinking)"
  CXX="$(GXXBinaryNameForLinking)"
  ...
>

Hence, you can redefine the GCCBinaryNameForLinking and GXXBinaryNameForLinking to arbitrary values in a PropertyGroup inside your project, and it will replace the default values.

[support]

Hi,

The advanced tracing currently only works on ARM. It involves dynamically generating code that saves the selected variable values, and this is only supported on ARM now. But you can still use Chronometer on any target that has a cycle counter. You will just need to edit the chronometer definitions to tell VisualGDB how to read it.

[support]

Hi,

The exact location of the setting depends on the project type. It is normally either in VisualGDB Project Properties, or VS-level properties that can be edited by right-clicking on the project in Solution Explorer. You can find more information about various project types here: https://visualgdb.com/documentation/projects/overview/

[support]

Hi,

VisualGDB is designed to work with any GCC-based toolchain that is otherwise usable (i.e. can build code without errors). You can point VisualGDB to it by selecting the import option at the bottom of the toolchain selector.

Same for compiler flags like the C_STANDARD: VisualGDB shows a suggestion list based on the XML files in its own directory, but you can always specify a different value, as long as your toolchain supports it.

Update: we have updated the ARM toolchain package that is automatically installed by VisualGDB to the latest release from ARM (14.2). You can install it via VisualGDB Package Manager.

• This reply was modified 4 months, 3 weeks ago by support. Reason: Mentioned updated package

[support]

Hi,

Sorry about that. It looks like an issue with the 8-bit STM8 device family. These devices are not as popular as 32-bit devices (e.g. STM32) so we do not retest them that often. We will try to address it in one of the upcoming maintenance releases.

If anyone else runs into the same issue, please feel free to check in here, and we will raise the priority of the issue.

As a quick workaround, you can try copying the PreprocessLinkerScript option definition from $(VISUALGDB_DIR)\MSBuild\PropertyPages\gcc\linker.xml  to MSBuild\PropertyPages\cxstm8\linker.xml, but it many not solve all the issues with STM8.

[support]

Sure, you can set Tools->Options->VisualGDB->CMake->Use pre-built CMake for Local Builds to false, and then change VisualGDB Project Properties -> CMake Build Settings -> CMake Command.

[support]

Thanks, this explains it. Something in the build scripts of a particular nRFConnect target triggers an internal error in a particular CMake version, so it silently crashes and VisualGDB doesn’t recognize it as normal error (since there is no error message). It could be related to this particular CMake version, or to some of our patches.

We would normally update the CMake shipped with VisualGDB in a few months after we are done prototyping a rather large feature planned for the next version. It should port all fixes from the mainline CMake, and is likely to resolve this issues as well.

If switching to the normal CMake until than works for you (or if you can narrow down a specific construct causing this), that should be the easiest way to handle it. If not, we can build a debug version of CMake so that you could capture a minidump and we could patch it, but it could involve several back-and-forth iterations.

[support]

It looks like you are still using VisualGDB 6.0R5. Please make sure you install VisualGDB 6.0R6. You can check the installed version via Help->About VisualGDB.

[support]

This is not a valid license. It will not work.

[support]

Hi,

It should work just fine. Please make sure you are using an unmodified VisualGDB installer and have a valid license.

[support]

Hi,

Unless the API is forced to the deprecated server mode (via Tools->Options->VisualGDB->CMake->API for querying CMake state), VisualGDB will automatically detect the API for each project.

It looks like it does attempt it here:

Restarting CMake in file mode...

Normally, the log should show what is happening next (VisualGDB trying to launch it in the file mode and possibly hitting some other error). If there isn’t anything obvious, please try the steps below:

1. Make sure it works with new project created from scratch on the same machine using the same CMake/toolchain.
2. Make a copy of the configuration log (it will contain similar lines for trying the server mode).
3. Get a log for the broken project and try comparing it against the working one. It should easily point out what is different.

If nothing helps, feel free to attach both logs here, and we can recheck.

[Author]

Posts