[support]

Hi,

Sorry, it looks like the SMB connection between the Linux machine and Windows machine fails at some point, but it’s not something VisualGDB can automatically fix.

You can try using the usual white box / black box troubleshooting:

• Capture a WireShark trace of network communication between Linux and Windows and analyze it. It should give a good insight into the cause (some SMB request will be failing with an error), but getting to the bottom of it will be a very tedious task, trying to understand thousands of network packets.
• Alternatively, you can try simplifying the repro. Instead of a build, try reading all sources one-by-one. If it doesn’t trigger anything, do it from multiple threads. Try varying the number of threads, making pauses, etc. If it turns out that some particular pattern triggers the problem (e.g. more than X threads in parallel), you might be able to work around it by tweaking the build process.

[support]

Hi,

Thanks for renewing your license.

The VC++ IntelliSense takes the language standard version from the ClCompile/LanguageStandard element in the .vcxproj file (note the condition attribute). You can try changing it via the VS project properties for the non-VisualGDB project and observe how the value changes (e.g. to stdcpp17).

VisualGDB uses separate language standard settings for C and C++ files (CLanguageStandard/CPPLanguageStandard), so the native VC++ IntelliSense does not pick them up automatically.

You can try manually copying the LanguageStandard element into the VisualGDB’s .vcxproj file (also under ItemDefinitionGroup/ClCompile) and reloading the solution. VisualGDB should ignore it, but the VC++ IntelliSense should pick it up.

 

[support]

Hi,

Thanks for reporting this. We have fixed it in this build: VisualGDB-6.0.103.5194.msi

[support]

Hi,

OK, we have rechecked the test discovery logic for the simulation platform and it should be possible to get multiple test targets working without any modifications on the VisualGDB side.

First of all, please try cloning this example and duplicating the add_bsp_based_executable() statement to add another target with a different name, but same sources. Then build the solution (simulation platform). Test Explorer should now show 2 sets of tests.

To replicate it in your solution, you would need to manually define a couple of cache variables via set(… CACHE INTERNAL “”)

1. For each executable, set <executable name>_TEST_FRAMEWORK_TARGET to the name of the static library target that corresponds to the test framework.
2. For the actual test framework, set <static library name>_TEST_FRAMEWORK_ID to com.sysprogs.unittest.googletest

You can check the variables defined by our example project by viewing the cache-v2-<id>.json file in <project directory>\.visualgdb\VisualGDBCache\EmbeddedSimulationDemo-Debug-Simulation\CodeModelCache. If your project manages to define the same cache variables, VisualGDB should be able to locate and discover all test targets and not just the startup one.

[support]

Hi,

Thanks for confirming this. In general, the VS IntelliSense is not directly controlled by VisualGDB. We can show you where it looks for settings like language standard and how to try manually applying them to a VisualGDB project, however it may still not work if it expects something specific to regular VC++ projects. If you would like to go ahead and try it, we would kindly ask you to renew your support first.

[support]

Hi,

The regular IntelliSense is managed directly by VS and might not support C++17 if you are using an older Visual Studio. Even the latest Visual Studio might not support some variants of GCC extensions.

Does IntelliSense work as expected with similar code on a regular Win32 project (non-VisualGDB based) and the same VS version?

[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 VisualGDB’s unit test logic was designed to handle many different device types that don’t always have an stdout stream. So, we patched the test frameworks to output the test results in a machine-readable format into a separate channel, independent from the main output, if any. The task of translating the test results into a machine-readable format is done on the target by the code in our patch. If you would like to eliminate the patch, you would need to create a separate proxy application that would read the test results from stdout, parse them via regexes, and forward them back to VisualGDB via the VisualGDB-specific format. If you are willing to implement it, we can add a setting for running an external test result translator, but using the patched versions of the test frameworks could be just easier. The patches are very straight-forward, can be easily applied to other test framework versions, and don’t change the test framework license.

You can use the CMake presets together with the simulation platforms, however it would involve manually editing some configuration files. First of all, please try adding a simulation platform to a regular Advanced CMake project and take a note of the changes it does to the .vgdbcmake file: it will add a new XML node in Configurations/VisualGDBConfiguration[PlatformName=”Simulation”] overriding the project settings (Embedded -> MinGW) and Debug Settings (Embedded Debug -> MinGW Debug). So, whenever you select the Simulation platform, VisualGDB will replace the project and debug settings with the ones from the Configuration node.

When using CMake presets, the Platform is fixed to the default one, and the preset names are mapped to configuration names. So, you can copy the Configuration element from the non-preset project into the same location in the preset-based .vgdbcmake file, and replace the <PlatformName>Simulation</PlatformName> with <Name>YourPresetName</Name>. This will override the settings for that preset just like it previously did for the Simulation platform.

The multiple unit test targets are indeed not supported yet. We will look into adding them and will post an update here in the next couple of weeks.

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

If the main() function calls the same entry point from the test framework, it should work just fine.

You should be able to get more details by opening View->Other Windows->VisualGDB Diagnostics Console, or by running test manually via VisualGDB.exe /runtests with the following environment variables set:

• VISUALGDB_SHOW_DIAGNOSTIC_OUTPUT=1
• VISUALGDB_VERBOSE_OUTPUT=1

If nothing helps, you can also try a black box approach:

1. Disable automatic project rebuilds.
2. Get 2 very similar proof-of-concept projects, one using our framework properly and another one having the files added manually.
3. Make sure the first one works.
4. Replace the binary file produced by the first project with the second one and retry running it.
5. If it still works, the problem is caused by something in the project settings. You can try comparing the .vgdbsettings files from both projects.
6. If the second binary copied in the first project doesn’t work, something inside the binary is off. You can try running objdump -t on both binaries to get the list of all symbols, sorting them by names, and comparing them via a diff tool. Any obvious differences (e.g. missing symbols or significantly different function sizes) should point to the root cause.

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

Thanks, we have linked your key to your profile.

You can configure the GDB signal handling behavior via the “signals” button in the GDB session window: https://visualgdb.com/documentation/gdbsession/#signals

[support]

Hi,

If the components registry is working on WSL, but not on regular Windows, it could be a bug in ESP-IDF. Using ESP-IDF via VisualGDB will not automatically fix it. Please make sure you can build it via Windows command line/batch file before trying to fix it on VisualGDB’s end.

If changing something via VisualGDB GUI crashes Visual Studio, please consider obtaining a call stack of the crash as shown here: https://visualgdb.com/support/callstack

[support]

Hi,

Thanks for sharing this!

[support]

Hi,

If you would like VisualGDB to pass an environment variable to CMake, you would need to set it via VisualGDB Project Properties -> CMake Project -> CMake Command -> Environment.

You can then double-check it by dumping the command used by VisualGDB to a batch file as shown here. The file should contain all environment variables set by VisualGDB and running it should produce the same result as building the project with VisualGDB.

[Author]

Posts