[support]

Hi,

Sure, you can do that. In principle, you would need to have 3 things:

1. The project should reference the unit test framework via VisualGDB Project Properties -> Unit Tests. Even if you don’t end up using the actual framework, simply having it referenced there will make VisualGDB look for tests in the project.
2. The binary produced by the project should actually contain the test symbols usually produced by GoogleTest. You can search for TestDiscoverers  in %LOCALAPPDATA%\VisualGDB\TestFrameworks\com.sysprogs.unittest.googletest\TestFramework.xml to get a basic idea of what VisualGDB is looking for.
3. The project’s main() function should actually pass control to the unit test framework, and the framework should contain our patches for selecting the tests via debugger, and for reporting test results via semihosting.

The easiest way to do it without using find_bsp/find_test_framework is to create a simple test project using the wizard, see what exact files (with what parameters) are included in it, and then reconstruct it in your own project.

[support]

Hi,

Sure, VisualGDB has a mechanism for customizing both target and item templates, although it wasn’t documented much.

We have added a page explaining it here: https://visualgdb.com/documentation/cmake/templates/

[support]

Hi,

No worries. For what it’s worth, the FreeRTOS Live Watch functionality is implemented in a separate open-source plugin, so you can always tweak it if your setup involves something very specific that otherwise doesn’t work.

[support]

Thanks, the “undefined reference” error is actually a glitch in the new 64-bit Raspberry Pi toolchain.

Please try creating the <SysGCC>\raspberry64\aarch64-linux-gnu\sysroot\etc\ld.so.conf file with the following contents:

/opt/vc/lib
# Multiarch support
/lib/aarch64-linux-gnu
/usr/lib/aarch64-linux-gnu
/usr/lib/aarch64-linux-gnu/libfakeroot
# libc default configuration
/usr/local/lib

We have also updated the toolchain on our side to include this file out-of-the-box.

• This reply was modified 7 months, 1 week ago by support. Reason: updated path

[support]

Hi,

Thanks for renewing. Please make sure you update to VisualGDB 6.0, then follow the steps below:

1. Delete the toolchain you have.
2. Download a toolchain from here that matches your SD card image.
3. Make sure you can build and debug a basic executable (non Qt-based) using that toolchain. If it doesn’t work, replace your SD card contents with a fresh image per our toolchain list.
4. Once the basic program works, follow our Qt/CMake tutorial to get everything working.

[support]

Hi,

Thanks, we have linked your key to your profile. Regarding this error, please try enabling View->Other Windows->VisualGDB Diagnostics Console and starting a profiling session without debugging.

If it still doesn’t work, please take a note of the valgrind command line shown in the VisualGDB diagnostics console. It will show the path to the profiled program and some other arguments.

Please then try manually running valgrind with that program without any other options, e.g.

valgrind /tmp/my-program

Does valgrind work when launched manually? If yes, please post the exact command line you captured from VisualGDB Diagnostics Console and the exact command that worked manually.

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

The file is automatically updated when VisualGDB is loaded inside Visual Studio. Just installing the toolchain outside VisualGDB won’t change it.

You can try running VisualGDB.exe /pkgmgr to force VisualGDB to reload the toolchain list.

If it doesn’t help, something else could be preventing VisualGDB from rebuilding the file. In this case please try renaming the file, restarting Visual Studio and creating a new MSBuild project using one of the toolchains using the wizard. If the file is not regenerated after it (or is missing some toolchains), please let us know and we will investigate it further.

[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 7 months, 1 week 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).

[Author]

Posts