Tagged: lcov unit test report
November 11, 2019 at 17:09 #26425
I would like to generate code coverage reports of our unit tests ran on the efr32. I have tried adding the flags to the compiler: https://email@example.com/generating-code-coverage-report-using-gnu-gcov-lcov-ee54a4de3f11
But that give me an:C++123Severity Code Description Project File Line Suppression State Suppression StateError undefined reference to `__gcov_init' UnitTest_CICD_testError undefined reference to `__gcov_exit' UnitTest_CICD_test
Could you guys help?
November 12, 2019 at 02:07 #26430
- This topic was modified 1 month ago by support. Reason: formatting
Sorry, code coverage is not supported for embedded projects yet. Obtaining the coverage for GCC-based projects requires a mechanism for transferring the coverage data from the target to the host, and there are a few caveats that make this task non-trivial. We are internally experimenting with it and will very likely support it in one of the next preview builds for v5.5. However, as of today, the only way to obtain code coverage for an embedded project would be to use Segger J-Trace (see this tutorial).November 12, 2019 at 09:49 #26439
Ok thanks, good to know! Do you have an ata for that release?November 16, 2019 at 01:40 #26466
Currently we are still researching the ways to reduce the RAM use by the profiling counters. We should be able to get an ETA for this feature around the middle of the next week.November 22, 2019 at 05:54 #26534
Just wanted to share an update that we have added support for embedded code coverage (including Live Coverage) to the following build: VisualGDB-18.104.22.16890.msi
You can enable it via VisualGDB Project Properties -> Code Coverage.
For most accurate results, please consider upgrading to the latest GCC 9.2.1-based ARM toolchain (that is a repackaged version of the official GNUARM toolchain).November 22, 2019 at 11:44 #26535
Thank you!November 28, 2019 at 09:26 #26600
I did some testing, but as soon as I enable the code coverage io run in to a issue. The compiler complains that the sram section is to small. This is due to the “-<strong class=”hu iv”>fprofile-arcs” which is automatically set because of the “–coverage flag”. Is this a known issue? (chip uses: EFR32MG1P232F256GM48)
November 29, 2019 at 11:27 #26645
- This reply was modified 2 weeks, 2 days ago by Markg.
I did some testing, but as soon as I enable the code coverage I run in to a issue. The compiler complains that the sram section is to small. This is due to the -profile-arcs which is automatically set because of the –coverage flag. Is this a known issue? (chip used: EFR32MG1P232F256GM48) Using the -fno-zero-initialized-in-bss does not solve the problem.
November 29, 2019 at 23:08 #26676
- This reply was modified 2 weeks, 1 day ago by Markg.
Most likely, you are not using the VisualGDB build engine to build the project. Just building the code with the –coverage flag will introduce immense memory overhead, so VisualGDB does some advanced pre-link patching to move most of the coverage logic to the PC side. Please try creating an MSBuild-based projects and check with it instead.
Alternatively, please try running the following command line after compiling the code, but before linking it:C++1VisualGDB.exe /decover <full path to the ELF file> <full paths to all .o files>
Then re-link your ELF file as usual. This will greatly reduce the memory overhead caused by the code coverage.
We are also preparing a tutorial showing the related settings and best practices. Feel free to follow us on Twitter to get notified once we publish it (or simply check our tutorials list next week).December 9, 2019 at 09:52 #26809
Is there an update on the tutorial?December 9, 2019 at 17:55 #26820
Yes, we have published the tutorial here: https://visualgdb.com/tutorials/profiler/embedded/coverage/
You must be logged in to reply to this topic.