Changes between Version 81 and Version 82 of TBR/UserManual/RTEMS_Coverage_Analysis


Ignore:
Timestamp:
09/23/09 19:48:13 (15 years ago)
Author:
GlennHumphrey
Comment:

Finished Beyond Object Code Coverage section

Legend:

Unmodified
Added
Removed
Modified
  • TBR/UserManual/RTEMS_Coverage_Analysis

    v81 v82  
    146146
    147147
    148 At this point, the RTEMS Code Coverage effort has been focused on Object Code Coverage.  But we would like to go beyond Object Code Coverage and address other traditional coverage criteria (see [wiki:Developer/Coverage/CoverageAnalysisTheory Coverage Analysis Theory]).  We would also like to remain true to our objectives of using freely available tools and to do the analysis without modifying the code to analyze.
    149 = Statement Coverage =
    150 
    151 
    152 This requires knowing which source files are involved (which we do) and which lines in those files can produce assembly code (which I don't think we do 100%).  We can easily know which lines are comments and blank but beyond that will require some thought. 
     148At this point, the RTEMS Code Coverage effort has been focused on Object Code Coverage.  But we would like to go beyond Object Code Coverage and address other traditional coverage criteria (see [wiki:Developer/Coverage/CoverageAnalysisTheory Coverage Analysis Theory]).  We would also like to remain true to our original guidelines of using existing tools and performing the analysis without modifying the code to analyze.
     149= Achieving Statement Coverage =
     150
     151
     152Achieving Statement Coverage requires knowing which source files are involved (which we do) and which lines in those files can produce assembly code (which I don't think we do 100%).  We can easily know which lines are comments and blank but beyond that will require some thought. 
    153153
    154154The current object coverage utility ''covmerge'' can be modified to generate a report of which source lines were covered. It could generate a bitmap per source file where the bit index indicates if a source line in that file was executed or not.  If we can generate a similar bit map from the source code which marks comments and other non-executable source lines as covered, then the union of the two bitmaps can be used to generate a report showing which source lines are not covered or represented in the object code.  This may indicate dead code or weaknesses in the tests.
    155155
    156156This is definitely an open project at this point.
    157 = Condition/Decision Coverage =
    158 
    159 
    160 QEMU -- project to do MC/DC .. update here
    161 
    162 TBD
    163 = MC/DC =
    164 
    165 
    166 From the RTEMS testing perspective, this is to verify that every branch instruction in the generated object has been both taken and not taken.  We cannot determine this without help from a simulator or hardware debugger which gathers this information.
    167 
    168 QEMU -- project to do MC/DC .. update here
     157= Achieving Condition/Decision Coverage =
     158
     159
     160Achieving Condition/Decision Coverage requires knowing whether each branch has been both taken and not taken.  The group responsible for the QEMU processor simulator is actively working to support coverage efforts.  QEMU produces a trace of the instructions executed when an executable is run.  The trace information could be analyzed to identify branch instructions and to determine whether the branch was taken and/or not taken.
     161
     162This is another open project at this point.
    169163= BSPs Analysed =
    170164