Forum Replies Created
-
Posts
-
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).
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.
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.
Thanks for the repro description. Indeed, our integration tests covered libraries and unit tests separately, but never tested them together, so we overlooked this scenario.
We have fixed the issue in this build: http://sysprogs.com/files/tmp/VisualGDB-5.4.100.2743.msi
The issue is likely caused by some internal changes between different ESP-IDF versions. Normally doing a full rebuild should fix this (if you can confirm this, we can update VisualGDB to trigger a full rebuild automatically if the project was previously built with a different toolchain).
Please let us know whether a rebuild fixes the problem. If not, please also try creating a new project with the new toolchain and let us know if that works.
Unfortunately we are still not sure what you meant. The logic for importing the macros is the same for both compilers.
If you are still trying to solve the original problem with the CRYP definition, please check the stm32_*_config.h file as suggested earlier. Depending on your project configuration, you may need to enable the CRYP module on the Keil Packages page of VisualGDB Project Properties (available in the Custom edition or higher).
If this is not what you are looking for, please let us know exactly the problem you are trying to solve.
No problem. For Make you could try doing the same manually (extract the gcc command line from the logs and then replace -c with -E and .o with .E and run it), but ultimately it may not be worth the effort.
Thanks, this indeed looks like VisualGDB doesn’t apply the test framework path properly. We have tried reproducing it on a newly created project, but could not get this behavior. It might be caused by some settings of this specific project. Please try checking if the problem persists on a newly created project. If not, please make a backup of the project, open VisualGDB Project Properties on the Test Framework page and change the framework back and forth. If this solves the problem, we would appreciate it if you could share the differences between the old and new project files so that we could fix it.
You could try enabling the preprocessor output (via VS Project Settings -> C/C++ if you are using MSBuild) to track this down (it will expand all preprocessor macros and include directives and save the output to a .E file), however disabling/ignoring this warning should be completely OK unless you are planning to port your code to ARM64.
Please try enabling the option in the “Find” window and then restart Visual Studio. Next time you start it, “nostop” will be automatically added to all entries in the target list.
You can disable the CodeJumps references by clicking at the tag button in the top right corner of the screen.
It is. If anyone else is willing to provide help with this, they are absolutely welcome to do that. We just wanted to clarify that we won’t be able to provide any support from our side unless you renew your license.
Hi,
Looks like your support period has expired. In order to receive technical support, please renew your license here: https://sysprogs.com/splm/mykey
VisualGDB would query the include search path by running gcc from the toolchain and letting it dump the specs (macros and include paths), so it’s usually very accurate.
Please try clicking on “int32_t” and select “Go to definition”. Does the file/location shown there make sense?
No problem. _sbrk() is usually implemented by the standard library (you can select the syscall implementation type on the first page of VisualGDB Project Properties). If you want to fine-tune the location of the heap, you can add your own implementation of this function (see this tutorial).
