Changes between Version 43 and Version 44 of TBR/UserManual/RTEMS_Coverage_Analysis

Timestamp:

09/16/09 22:32:53 (15 years ago)

Author:

GlennHumphrey

Comment:

/* What was Discovered */ Improved NOP discussion

TBR/UserManual/RTEMS_Coverage_Analysis

@@ -56 +56 @@
 
 
-When we began the RTEMS Code Coverage effort, we performed coverage analysis on the developmental head of RTEMS 4.8 using the POSIX Enabled Profile.  Some of our initial observations were interesting.  First, we were a little surprised at the incompleteness of the test suite.  We knew that there were some areas of the RTEMS code that were not tested at all, but we also found that areas we thought were tested were only partially tested.  We also observed some interesting things about the code we were analyzing.  We noticed that the use of inlining sometimes caused significant branch explosion.  This generated a lot of uncovered ranges that really mapped back to the same source code.  We also found that coding habits and coding style generated a lot of unreachable object code.  Also, the use of a case statement instead of an if statement sometimes lead to unreachable code.
-
-Some of our observations were related to the performance of the ''covmerge'' tool.  Of particular interest was the handling of NOP instructions.  Compilers can use NOP instructions to force alignment between functions.  Of course the NOP instructions are not executed and thus had a negative impact on the coverage.  The first attempt at dealing with NOP instructions was to mark them as EXECUTED.  This produced an unwanted side affect of occasionally spliting an uncovered range into two ranges.  We finally settled on an improved method for dealing with NOPs where NOPs were marked as EXECUTED unless they were between two un-EXECUTED instructions.
+When we began the RTEMS Code Coverage effort, we performed coverage analysis on the development head of RTEMS 4.8 using the POSIX Enabled Profile.  Some of our initial observations were interesting.  First, we were a little surprised at the incompleteness of the test suite.  We knew that there were some areas of the RTEMS code that were not tested at all, but we also found that areas we thought were tested were only partially tested.  We also observed some interesting things about the code we were analyzing.  We noticed that the use of inlining sometimes caused significant branch explosion.  This generated a lot of uncovered ranges that really mapped back to the same source code.  We also found that coding habits and coding style generated a lot of unreachable object code.  Also, the use of a case statement instead of an if statement sometimes lead to unreachable code.
+
+Some of our observations were related to the performance of the ''covmerge'' tool.  Of particular interest was the handling of NOP instructions.  Compilers can use NOP instructions to force alignment between functions or to fill delay-slots required by the processor.  Of course the NOP instructions are not executed and thus had a negative impact on the coverage.  The first attempt at dealing with NOP instructions was to mark them all as EXECUTED.  This was correct for the NOPs used for function alignment, but not for NOPs used for delay-slots.  Marking delay-slot NOPs as EXECUTED produced an unwanted side effect of occasionally spliting an uncovered range into two ranges.  We finally settled on an improved method for dealing with NOPs where NOPs were marked as EXECUTED unless they were between two un-EXECUTED instructions.
+
+SHOW SAMPLE CODE
+
+Creates more uncovered case to examine.
 = Resolving Uncovered Code =