GSoC 2018 Final Report

Project Overview

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.

Mentors

• Dr. Joel Sherrill
• Chris Johns
• Cillian O’Donnell

Project Objectives

There are two main objectives of the project.

1. Integrating a script in RTEMS-TESTER framework to invoke the covoar tool 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.

2. Add support in Covoar to take input from the qemu traces and the gcno files which are generated by gcc at the compile time, and process it to generate the gcda data 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 xml which 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…

It got merged !!!

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.

HTML reports. Text reports

Future Improvements

• 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 gcno_dumper project 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.

Description of the working of the gcno_dumper tool and the discussion on the generated txt file can be found in THIS and THIS link. The full dump txt file can be found in THIS LINK

Future work

• Complete the gcno_dumper tool.
• Create a gcda_dumper similar 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).

Project Wiki

Weekly Progress and status update

I thank my mentors and all the members of THE RTEMS PROJECT for being such an awesome and supportive community, it was a great summer of challenges, learning and a lot of fun!