- GSoC 2018 Final Report
- Taking Notes: Understanding the GCNO dump part 1
- Note it : The gcno files
- Getting started with Gcov support
- Summarizing Phase 1
- Text Report of Coverage analysis
- Report Card : The Coverage analysis report
- The right Path : Getting path to build-directory
- GSoC 2018 project Introduction : Improve Coverage Analysis Toolset
- All posts ...
GSoC 2018 Final Report
Aug 6, 2018 • Vijay Kumar Banerjee(thelunatic)
RTEMS-TOOLS Uses the test framework
rtems-test, which is a command line
interface to run tests on supported targets.The Board Support Package (BSP)
configuration for RTEMS are provided and can be used to run all the tests
provided in the RTEMS testsuites. The framework is not specific to RTEMS and
can be configured to run any suitable application.
- Dr. Joel Sherrill
- Chris Johns
- Cillian O’Donnell
There are two main objectives of the project.
Integrating a script in RTEMS-TESTER framework to invoke the
covoartool to generate Coverage Analysis reports and output in a front-end HTML Table to let the user easily navigate through all the reports from one place.
Add support in
Covoarto take input from the
qemutraces and the
gcnofiles which are generated by gcc at the compile time, and process it to generate the
gcdadata files. The notes (gcno) and the data files (gcda) can be processed by the GCC GCOV to generate gcov reports which opens door to reports with more data-centric format like
xmlwhich can be processed by other tools.
Summary of The Work
This section contains a detailed summary of the work done towards each of the two objectives mentioned above. This includes the Challenges faced specific to the objective, the work done and the progress towards the goal and the future of the project.
Integrating Coverage script in Tester-Framework
This was the continuation of the GSoC 2017 project of Cillian (one of my mentors).
I picked up from the point where he left, it was not merged with the RTEMS-TOOLS
main repository yet, the source tree had undergone significant reorganization,
early this year, which resulted in the breaking of the coverage script, the
coverage reports were yet to be produced by the script. The project kept
evolving with time and the script as well as
covoar underwent a lot of
refactoring and reworking.
THIS LINK has the list of the commits that got the script working and reports could be generated.
What was needed to be done after this was some refactoring of this code and adding support in the script to generate absolute build paths and proper ini files. After quite some work and reworking of the code, I squashed all the patches into one, and then…
I have two patches pending review, these add the support in coverage, to iterate over the symbol-sets in the symbol-sets.ini file, and produce separate reports for each of the symbol-set.
- Patch to add support to generate separate reports
- Patch to add the symbol-sets and libraries in the ini file
Once the coverage patch above gets merged as well, this objective will be COMPLETE !
Running Coverage with RTEMS-TEST
The instructions for running the tester with –coverage option can be found here.
The detailed sample reports with images and explanations can be found in the following links.
- The support for iterating through multiple symbol-set to generate separate reports, can be shifted to Covoar, this will make it a lot faster.
- support for MCDC (Modified Condition/Decision Coverage) analysis.(This one is a long term goal and a good project in itself)
- Integrating detailed coverage analysis docs and how-tos with the tester docs.
Adding Gcov support in Covoar
This part of the project was really a challenge. The code related to Gcov support in RTEMS repo used to work at some point of time and it used to generate some reports which were not trusted due to the discrepancies and mismatch with the non-gcov reports generated by covoar. The biggest challenge was the fact that the code was very old and the RTEMS source tree underwent significant reorganization recently, after which gcov support in covoar was not updated.
I started taking a dig into the code in
GcovData.cc which is responsible for
reading the gcno files, writing the gcda files and running gcov command for each
symbols. On using the gcov arguments,
covoar was running into Segmentation
faults. These are my commits to GcovData.cc to clear the seg faults.
- Experiment with the source filename to add absolute path
- Add support to derive source file name from the gcno file
These might have solved the segmentation faults, but we were still far from reports and the main hurdle on the way was the mystery of the gcno files. We didn’t have much knowledge about the gcno files which was very necessary in order to parse it properly and then generate the gcda files with it.
To solve this I started a making a gcno dumper tool,following my mentor,
Dr. Sherrill’s advice. I have added the code of the
in a separate public repository.
This is the link to the repo…
This is currently working and it dumps all the data from gcno files into a
txt file in human readable format, it needs to be reviewed and after the review
and needed modifications it will go into the
covoar/, this will help debug the gcov reports.
- Complete the gcno_dumper tool.
- Create a
gcda_dumpersimilar to the gcno_dumper. Once gcno dumper is made it will be simple to get a gcda dumper as they have similar format.
- Update the source code in GcovData.cc to use the approach applied in the dumper tool.
- Get gcov reports generated again. (This is a long term goal and this needs all the above mentioned points addressed first).