[support]

Yes, we will try to add something similar in one of the next major releases.

[support]

Hi,

The file might be a part of a static library. Normally checking the output in the View->Output window should help find the full path of the files with both definitions.

Alternatively please try disabling syscall implementations via the first page of VisualGDB Project Properties.

[support]

Hi,

Sorry about that, it indeed looks like our bug. Please try this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2751.msi

Please replace the <Linux> section inside the %LOCALAPPDATA%\VisualGDB\TestFrameworks\com.sysprogs.unittest.googletest\TestFramework.xml file with the following lines:

  <Linux>
    <AdditionalSourceFiles />
    <AdditionalHeaderFiles />
    <AdditionalPreprocessorMacros />
    <AdditionalLibraries>
      <string>pthread</string>
    </AdditionalLibraries>
    <InitializationLines>
      <string>testing::InitGoogleTest(&amp;argc, argv);</string>
      <string>return RUN_ALL_TESTS();</string>
    </InitializationLines>
    <AdvancedTestDiscoverers>
      <TestDiscoverer xsi:type="OutputBasedTestDiscoverer">
        <TargetDemangledNames>true</TargetDemangledNames>
        <CommandLineArguments>--gtest_list_tests</CommandLineArguments>
        <TestGroupRegex>^(|[^/]+/)([^ \t/]+)\.$</TestGroupRegex>
        <TestRegex>^[ \t]+([^ \t/]+)(|/[^ \t/]+)($| )</TestRegex>
        <UniqueNameFormat>{1}{2}_{4}{5}</UniqueNameFormat>
        <StructuredInternalNameFormat>{1}{2}.{4}{5}</StructuredInternalNameFormat>
        <UserFriendlyNameFormat>{1}{2}::{4}{5}</UserFriendlyNameFormat>
        <SecondaryIDFormat>{1}{2}::{4}{5}</SecondaryIDFormat>
        <ShortUserFriendlyNameFormat>{4}{5}</ShortUserFriendlyNameFormat>
        <LocationSymbolFormat>{2}_{4}_Test::TestBody()</LocationSymbolFormat>
      </TestDiscoverer>
    </AdvancedTestDiscoverers>
    <TestSelection xsi:type="ArgumentBasedTestSelection">
      <GlobalArgumentTemplate>--gtest_filter=$(PerTestArguments)</GlobalArgumentTemplate>
      <PerTestArgumentTemplate>$(1).$(2)</PerTestArgumentTemplate>
      <PerTestArgumentSeparator>:</PerTestArgumentSeparator>
      <TestIDRegex>(.*)::(.*)</TestIDRegex>
      <IDType>SecondaryID</IDType>
    </TestSelection>
    <TestReportChannel xsi:type="PipeBasedTestChannelWithEnv">
      <PipeTimestampVariableName>g_SysprogsTestReportTimestamp</PipeTimestampVariableName>
      <EnvironmentVariableName>SYSPROGS_TEST_REPORTING_PIPE</EnvironmentVariableName>
    </TestReportChannel>
  </Linux>

We will publish an official update to our googletest package after the next maintenance release (R2) in the next few days.

[support]

Hi,

Thanks  for reporting this. We have fixed it in the following build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2751.msi

[support]

Hi,

Sorry, the hardware registers window indeed only works when the target is stopped currently. We are planning to redesign it in the next major VisualGDB release, and this will also enable register updating while the target is running.

As a workaround, please try adding specific registers to Live Variables (the special Watch window that does get updated while the target is running). Let us know if you need more details on that and we will be happy to help.

[support]

Hi,

Could you have accidentally deleted the .vgdbsettings file mentioned in the error? Please try creating a new test project from scratch. Are you able to run the tests from it? Does switching the new project to the Release configuration (you would need to build the project after switching the configuration) result in an error again?

[support]

Hi,

It looks like your technical support has expired. Please renew it here and we will be happy to help you find the correct configuration.

[support]

Hi,

No problem. We have merged our patches into CMake 3.13.3 and updated our package. You can remove the %LOCALAPPDATA%\VisualGDB\CMake directory and restart Visual Studio. This should get CMake 3.13.3 installed instead of the previous version.

[support]

Sorry about that. Generally, based on our experience with Espressif’s tools, they are very sensitive to the specific toolchain/IDF versions. We had observed strange build-time and runtime errors after using a slightly different toolchain version that Espressif recommends, so we switched to picking up toolchain/IDF combinations recommended by Espressif, running minimal tests on them and shipping them in a way that can be seamlessly used with VisualGDB.

If Amazon is using a different version of the IDF, we would generally advise first importing it as an external embedded project with the toolchain tested by Amazon, using their OpenOCD build (manually configuring it via the “custom gdb stub”) and confirming that everything works. Then you could try replacing some of the components (e.g. OpenOCD) with the ones that come with VisualGDB.

We might be able to support this out-of-the-box once we see a considerable fraction of ESP32 users interested in this setup, however currently maintaining another stack of tools and a separate branch of the Advanced ESP-IDF Project Subsystem specifically for the Amazon FreeRTOS codebase is unfortunately more than we can offer, sorry.

[support]

Hi,

Thanks for the project link. It looks like the demo project is using a fairly old version of ESP-IDF that might not be compatible with the latest toolchain, or may not work reliably at all.

You can configure VisualGDB to use it by selecting the “import” option in the ESP-IDF selector on the first page of VisualGDB Project Properties. However, as it’s a relatively old ESP-IDF release, it may not work as expected and we would not advise doing that.

You can also import the project into VisualGDB as a regular external embedded project (see this tutorial). VisualGDB will then run the command line specified by you and will not make any assumptions about the project structure.

Generally, we would advise instead using the regular toolchain + ESP-IDF installed by VisualGDB and importing projects into this workflow. This will let you use the combinations of components that were tested together and will reduce the amount of errors you would have to resolve.

[support]

The Amazon FreeRTOS demo is likely ARM-specific, so you cannot directly import it “as is” into an ESP32-based project.

However you can create a regular project with ESP-IDF (see this tutorial) that will include a special port of FreeRTOS provided by Espressif. You can then call the regular FreeRTOS functions (same as called from the demo) from your main source file.

[support]

Hi,

ESP-IDF is already based on FreeRTOS, so no explicit action is required to use it – every project based on ESP-IDF includes a port of FreeRTOS.

[support]

Hi All,

The GCC itself it very stable (it’s used to build the Linux kernel that powers most of the servers nowadays), so the problem is likely caused by either your code or some libraries.

The only advice we could give is to try changing optimization level on specific files (it’s easy to do via VS Project Properties for MSBuild-based projects) in order to pinpoint the exact one. You can also try using the #pragma optimize to override optimization for specific functions (the #pragma will affect the rest of the source file unless you put another #pragma optimize there).

[support]

Hi,

Most likely this happens due to the missing mkfifo executable, or missing permissions. Please try running mkfifo /tmp/01d673d5-eb13-41d1-999a-8c7eda47ea45 manually via SSH to see why it fails. As soon as you fix the underlying issue, you should be able to run tests as usual.

[support]

Hi,

Normally, you should be able to reference the AAR library from another Android Studio project and then import the outer project into VisualGDB (see this tutorial). The classic VisualGDB projects (Ant-based) do not support AAR files as it is Android Studio-specific format.

We can help you import the Gradle-based project into VisualGDB, however that would require renewing your license to get the technical support active.

[Author]

Posts