New test hitting timespecs

[Joel Sherrill]

FWIW is your 0001 patch for message queue ready to merge? I seem to
have missed the final version to merge.

On 08/25/2012 05:50 AM, Krzysztof Mięsowicz wrote:
> Hi,
>
> As mentioned in earlier message I am working on eliminating uncovered 
> ranges in _Timespec_.... directives. I wrote new test which should 
> execute all instructions and cover all branches in these directives. I 
> am sending it in attached patch. Please, review it and point its 
> shortages.
There is precedence in new sptests to use a name of some sort. How about 
sptimespec01?
I wish we had started that nomenclature back in the earliest days of the 
project. At least
git makes it easy to rename things so it isn't too late but the tests 
will have to be
gone through.

Here are my comments:

+ One variable per declaration (Init0
+ blank line between declarations and code (Init)
+ single blank lines
+ Use only C comments in C code
+ We have learned that putting a comment above each block of test code
     as to its purpose helps a lot in the future. This is again a lesson 
learned
     Simple comments even help like "basic test of add_to" or "divide by 0"
     save a lot of time in retrospect. Also if you change the environment in
     a way that a test
+ sometimes creating a subroutine for a related set of test cases helps
     keep a test from getting huge. If you have logical blocks of tests, 
this
     can help. Random ideas are like "normal add_to", "add_to_errors", etc
     Just an organization tip.
+ The .scn file needs dos2unix run on it. :)

This reminds me that I have been collecting notes on RTEMS Coding Style
and Rules and I probably just added more to it.
>
> However, analysis give me some strange results. This new test cover 
> all instructions indeed, but in coverage report there are some ranges 
> defined as uncovered which size in bytes is 1 or 2, but size in 
> instructions is 0! I'm confused with it and wonder how it is possible? 
> Could you explain me it, please?
>
Ignore it for coverage testing but please try to help us narrow down what
input is resulting in this being generated,

This confuses us also. It didn't happen initially and we didn't change 
the program. I
believe it happened due to some odd formatting change in the objdump 
output and
it tricked the objdump reader in covoar.

Have I showed you how to run this (by hand) on just a one or a few 
executables and a
small set of symbols? That  makes the runs faster and it focuses things down
on what you care about.

If you are running just your new test and getting this, then it would 
help us fix it.
I don't think it is hard to fix. We just need to know what confuses the 
reader.

> Krzysztof