Notice: We have migrated to GitLab launching 2024-05-01 see here: https://gitlab.rtems.org/

Changes between Version 19 and Version 20 of GCI/Documentation/CoverageAnalysis/Coverage


Ignore:
Timestamp:
12/09/18 05:54:26 (5 years ago)
Author:
shashvat jain
Comment:

fixed some broken links

Legend:

Unmodified
Added
Removed
Modified
  • GCI/Documentation/CoverageAnalysis/Coverage

    v19 v20  
    2020Traditionally, Code Coverage Analysis has been performed by instrumenting the source code or object code or by using special hardware to monitor the instructions executed.  The guidelines for the RTEMS code coverage effort were to use existing tools and to avoid altering the code to be analyzed.  This was accomplished by using a processor simulator that provides coverage analysis information.  The information was processed to determine which instructions are executed.  We called this Object Code Coverage and we defined 100% tested to be 100% Object Code Coverage.
    2121
    22 In addition to defining the method for determining 100% tested, it is also important to define what is actually being tested.  We accomplished this by defining a set of [wiki:RTEMS_Coverage_Analysis#Coverage_Profiles Coverage Profiles] that allowed us to specify the feature set, configuration options and compiler options used when performing the analysis.  This was important for two reasons.  First, it allowed us to simplify the problem space (uncovered code) so that the goal was attainable.  Second, we wanted to recognize that not all RTEMS users configure RTEMS in the same manner and we wanted 100% tested to be applicable to as many user configurations as possible.  The first profile that we defined encompassed the RTEMS executive and was called the Baseline/-Os/POSIX Enabled Profile.  The RTEMS executive is a large body of code that is generally defined to contain the score, sapi, rtems, and posix directories in the cpukit directory.  This represents the full tasking and synchronization feature set.  More details about [wiki:RTEMS_Coverage_Analysis#Coverage_Profiles Coverage Profiles] are discussed below.  Initially, we set out to achieve 100% Object Code Coverage of the Baseline/-Os/POSIX Enabled Profile.
     22In addition to defining the method for determining 100% tested, it is also important to define what is actually being tested.  We accomplished this by defining a set of [wiki:/GCI/Documentation/CoverageAnalysis/Coverage#CoverageProfiles Coverage Profiles] that allowed us to specify the feature set, configuration options and compiler options used when performing the analysis.  This was important for two reasons.  First, it allowed us to simplify the problem space (uncovered code) so that the goal was attainable.  Second, we wanted to recognize that not all RTEMS users configure RTEMS in the same manner and we wanted 100% tested to be applicable to as many user configurations as possible.  The first profile that we defined encompassed the RTEMS executive and was called the Baseline/-Os/POSIX Enabled Profile.  The RTEMS executive is a large body of code that is generally defined to contain the score, sapi, rtems, and posix directories in the cpukit directory.  This represents the full tasking and synchronization feature set.  More details about [wiki:/GCI/Documentation/CoverageAnalysis/Coverage#CoverageProfiles Coverage Profiles] are discussed below.  Initially, we set out to achieve 100% Object Code Coverage of the Baseline/-Os/POSIX Enabled Profile.
    2323
    2424An issue that had to be addressed from the very beginning was the different coverage map formats.  Each source of a coverage map (e.g. simulator, hardware debugger, etc.) may produce a coverage map in a different format.  The ''covmerge'' tool is implemented using C++ classes and provides for inheriting new Coverage Reader and Writer classes for specific coverage map formats.  This allows different formats to be converted to the internal representation used by ''covmerge'' and its replacement ''covoar''.  The ''covoar'' program currently supports the formats produced by the TSIM, Skyeye , and Qemu simulators.
     
    7777by default, it runs coverage analysis for all the sets.
    7878
    79 Please visit [https://thelunatic.github.io/rtems_gsoc18/blog/coverage-report/ my development blog] to see examples of coverage report
     79Please visit [https://thelunatic.github.io/rtems_gsoc18/blog/coverage-report/development blog] to see examples of coverage report
    8080
    8181== Coverage Analysis Report ==