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

Changes between Version 87 and Version 88 of TBR/UserManual/RTEMS_Coverage_Analysis


Ignore:
Timestamp:
06/04/10 19:24:36 (14 years ago)
Author:
JoelSherrill
Comment:

/* Current Status */ Add initial write up on status.

Legend:

Unmodified
Added
Removed
Modified
  • TBR/UserManual/RTEMS_Coverage_Analysis

    v87 v88  
    165165
    166166The [wiki:Developer/Coverage/Status Code Coverage Status] section lists the RTEMS BSPs on which we are performing (or would like to perform) Object Code Coverage.  We would like to continue to grow this list.  If you know of a simulator that includes coverage analysis, please let us know.
     167
     168With the instruction level coverage of core of RTEMS (e.g. score, rtems, posix, and sapi directories) near 100%, we have expanded our attention to to include other non-networking portions of the cpukit.  The following areas have been identified as good candidates for writing tests which improve the current coverage. 
     169
     170 *  FIFO/Pipe
     171 *  Untar
     172 *  TBD
     173
     174If you are interested in writing some simple parameter check error cases, then take a look at the branch taken/not taken coverage reports for the "core configuration". Some of these are a simple matter of adding missing test cases for bad parameter path.  Other cases are more difficult.  So if you run into trouble with the analysis, ask or skip it. A common pattern is this:
     175
     176{{{
     177if (arg1 bad)
     178  return EINVAL;
     179if (arg2 bad)
     180  return EINVAL;
     181}}}
     182
     183GCC is smart enough to optimize the returns into one block of code.  Thus we could have a test for arg1 or arg2 bad and obtain 100% instruction coverage.  But would not get 100% branch coverage.
    167184= References =
    168185