[support]

Hi,

Thanks for renewing your licenses. We will be happy to help.

For MSBuild projects, VisualGDB locates the toolchains as shown below:

1. The .vcxproj file defines the ToolchainID and ToolchainVersion variables.
2. MSBuild loads the %LOCALAPPDATA%\VisualGDB\FindToolchain.props file that matches these variables against a list of installed toolchains, and sets ToolchainDir.
3. The rest of the build rules run the compiler and other tools from ToolchainDir.

Normally, this should only find the toolchain if both ID and version match, or the version is not specified. However, modifications to project files or FindToolchain.props (e.g. hardcoding the toolchain directory) would interfere with it.

We would suggest double-checking the relevant variable definitions in the .vcxproj file and FindToolchain.props. E.g. you can try setting the version, ID, or the toolchain directory to completely broken values that would trigger a build error to see which of the statements get actually processed. It may turn out that some other property sheet or imported project file overrides some of the variables in a completely unexpected way.

[support]

You can use the following trial extension voucher to get extra 15 days of the trial: [removed]

In Visual Studio try starting the VisualGDB trial, if you have exceeded the trial days then it will fail and display a field to enter the trial extension voucher code. If you are currently using the trial then the field will also appear once your trial ends. The extra trial time will start counting down only once you use the trial extension code.

Feel free to contact us for support if you have any questions or issues setting up your projects with VisualGDB.

• This reply was modified 8 months, 4 weeks ago by support. Reason: removed voucher code

[support]

Hi,

We have received all 6 emails from you and answered all of them within a day each. However, it looks like your spam filter is deleting our replies.

We do not know why it blocks the replies from our ticket system, but not from the forum. Either way, you can post your questions here if you prefer. We treat email inquiries and forum inquiries the same way and try to answer them within 2 business days.

Regarding that specific error, it looks like something in your system is indeed resetting the environment variables for the Visual Studio process. It could be a bug in the antivirus software, or some particular global settings you configured earlier. Either way, VisualGDB requires the VISUALGDB_DIR environment variable to point to its installation directory, which is normally configured automatically by the VisualGDB’s installer, but can also be set manually via regular Windows settings. If something is resetting that variable, you would need to find out what program is causing it, and find a way to disable it.

[support]

Hi,

Normally, it should work just fine. This specific error means that the debugging symbols in the executable do not contain the xQUEUE or Queue_t type, so VisualGDB does not have sufficient information to decode the state of the internal FreeRTOS structures.

Please double-check that the debugged program is actually using FreeRTOS and has valid debugging symbols. Queue_t should normally be defined in queue.c. You can also double-check that the symbols reference it by checking sizeof(Queue_t) in the regular Watch window.

[support]

Hi,

You can actually easily do it via the editor tab context menu. Simply double-click on the file in question in Solution Explorer so that VS opens it in another tab, right-click on the tab header and select “Open Containing Folder”. It will open the file location in Explorer, and will pre-select the actual file.

[support]

Hi,

No problem. Both ways to edit settings are supported, there was just a glitch with applying the dark theme when opening it inside the VS file editor.

We have fixed it in this build: VisualGDB-6.0.101.5173.msi​

[support]

Hi,

OK, we rechecked everything again. If you check the “existing toolchain.cmake” checkbox in the wizard, but do not specify a file, VisualGDB will ask whether you want to proceed without using a toolchain file at all (equivalent to setting DisableToolchainFile  to true). However, the VisualGDB Project Projecties window indeed did not allow enabling this mode.

We have updated it to allow selecting any of the 3 options (existing file, generated file, no file) in this build: VisualGDB-6.0.101.5173.msi​

We will also look into decoupling generated toolchain files from the reference to the VisualGDB’s embedded project framework (that adds commands like find_bsp() and also changes some build flags).

[support]

Hi,

Sorry for the glitch with the forum. We have recently updated the WordPress/bbPress used for the forum, and it turns out that it silently flags posts with more than 1 hyperlink as “pending review”, but doesn’t actually show them anywhere unless you use a special viewing mode.

We have fixed the issue now, pending posts are now properly wired into our internal ticket system.

Regarding the problems with the toolchain, the toolchain testing logic is designed to catch common errors with regular toolchains (e.g. trying the x64 toolchain with an ARM target) and will produce false positives with less commonly used setups. You can simply ignore the errors and should still be able to setup a project. Also, simply ignore the gdbserver configuration as well.

The last error looks like the recently added support for the CXSTM8 toolchain broke MSBuild profile generation for LLVM. We have fixed it in this build: VisualGDB-6.0.101.5158.msi​. If it still doesn’t work, you can try creating a project with CMake instead of MSBuild. It relies on CMake to handle the low-level configuration instead of trying to handle everything on VisualGDB side (it can still trigger issues within CMake itself though).

With LLDB, VisualGDB relies on the lldb-mi tool that allows running lldb with the gdb-mi interface. As of 2024, the tool is unmaintained and not included in the normal llvm repository. VisualGDB includes an older version of lldb-mi based on lldb 6.0, however if it doesn’t work with the FreeBSD lldb server, you would need to either build a newer version yourself from sources, or simply use the gdb/gdbserver setup similar to Linux.

 

 

[support]

Hi,

It looks like your technical support period has expired. We would be happy to help you, however we would kindly ask you to renew your technical support on the following page first: https://sysprogs.com/splm/mykey​

[support]

Hi,

Looks like your browser automatically unzips the package when downloading (it’s a .tar.gz file). The correct (gzipped) MD5 should be ff56c76650114839e718ce8e4265ffac.

You can try downloading it with wget, re-gzipping the unzipped file, or just manually renaming it to .tar and extracting to the destination directory.

[support]

The toolchain.cmake file generated by VisualGDB normally just points CMake to the toolchain executables. Unless you manually edit toolchain definition files, it would not inject any implicit flags there.

You can try completely deleting and reinstalling both VisualGDB and the toolchain and creating a new project from scratch. If the toolchain.cmake file generated by VisualGDB still contains optimization flags after it, feel free to attach it here and we will investigate.

[support]

If you already have an existing toolchain.cmake file, we would advise simply pointing VisualGDB to it instead of creating a new empty one.

Edit: you can also try manually setting DisableToolchainFile in the .vgdbcmake file to false to completely disable the VisualGDB-level handling of toolchain files.

• This reply was modified 9 months ago by support. Reason: Mentioned DisableToolchainFile

[support]

Hi,

Thanks for the repro steps. If you do not want VisualGDB to generate a toolchain.cmake file, please try using the “Use existing CMAKE_TOOLCHAIN_FILE” option on the import page of the wizard (step 5 in the PDF). You can also change it via VisualGDB Project Properties (Step 6, second setting from the bottom in the first group).

[support]

Hi,

It really depends on how you imported the project and toolchain.

If you need help locating the relevant setting, please make sure you can reproduce the issue on a new project created from scratch. Then, please share the exact steps needed to reproduce it, along with the relevant screenshots, and we will try to point out the setting that is causing this.

[support]

Hi,

Then VisualGDB should not change any flags unless you have overridden it somewhere.

You can export the exact build/configuration commands used by VisualGDB as described here and compare them against the manual build commands.

[Author]

Posts