[PATCH] covoar: fixing the extension mismatch in trace file

Sun May 13 11:32:14 UTC 2018

But you see the thing is that if you remove the changes you made and run
the tester from the top of the build tree it makes it past those checks and
does full coverage analysis runs for all trace files that end in only .cov.
So only hello.cov here because I've changed it manually.

warning: Unable to read coverage file:
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.cov
Processing multiple executable/coverage file pairs
Coverage Format : html
Target          : sparc-rtems5

Coverage file
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.cov
for executable:
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Loading symbol sets:
/home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/score-symbols.ini
 Symbol set: score
 Loading library: sparc-rtems5/c/leon3/cpukit/score/libscore.a
Analyzing 382 symbols
Extracting information from:
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Created unified coverage map for _RTEMS_Lock_allocator (0x0 - 0x13)
Created unified coverage map for _RTEMS_Unlock_allocator (0x0 - 0x13)
Created unified coverage map for _API_Mutex_Lock (0x0 - 0x2f)
..............
Processing coverage file
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.cov
for executable
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Preprocess uncovered ranges and branches
Computing uncovered ranges and branches
Branch always taken found in _API_Mutex_Lock (0x40005f98 - 0x40005f9b)
Branch always taken found in _API_Mutex_Unlock (0x40005fc0 - 0x40005fc3)
Branch never taken found in _Chain_Initialize (0x4000600c - 0x4000600f)
Branch always taken found in _Freechain_Get (0x40006070 - 0x40006073)
Branch never taken found in _Freechain_Get (0x40006084 - 0x40006087)
Branch never taken found in _Heap_Allocate_aligned_with_boundary
(0x40006108 - 0x4000610b)
........................
Calculate statistics
Looking up source lines for uncovered ranges and branches
Looking up source lines for uncovered ranges in CSWTCH.1
Looking up source lines for uncovered branches in _API_Mutex_Lock
Looking up source lines for uncovered ranges in _API_Mutex_Unlock
Looking up source lines for uncovered branches in _API_Mutex_Unlock
Looking up source lines for uncovered branches in _Chain_Initialize
Looking up source lines for uncovered ranges in _Freechain_Get
............................
Generate Reports
Generate index.txt
Generate annotated.txt
Generate branch.txt
Generate uncovered.txt
Generate sizes.txt
Generate symbolSummary.txt
Generate index.html
Generate annotated.html
Generate branch.html
Generate uncovered.html
Generate sizes.html
Generate symbolSummary.html
Writing Not Found Report
(/home/cpod/development/rtems/leon3/coverage/score/ExplanationsNotFound.txt)
Coverage run for score finished successfully.
-----------------------------------------------
Generating reports
Coverage analysis finished. You can find results in
/home/cpod/development/rtems/leon3
***Cleaning tempfiles***

So there does seem to be some knock on effect of just tacking on .cov
there. Can't see all the consequences immediately but I'm having a look
now. I'll let you know if I find anything.

On 13 May 2018 at 12:07, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
wrote:

>
>
> On 13 May 2018 at 16:16, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
> wrote:
>
>>
>>
>> On Sun, 13 May 2018, 16:15 Vijay Kumar Banerjee, <
>> vijaykumar9597 at gmail.com> wrote:
>>
>>>
>>>
>>> On Sun, 13 May 2018, 16:09 Cillian O'Donnell, <cpodonnell8 at gmail.com>
>>> wrote:
>>>
>>>> It does seem to be having some knock on effect. Covoar made it past
>>>> these checks before.
>>>>
>>>> -----------------
>>>> Total:         13
>>>> Average test time: 0:00:03.178923
>>>> Testing time     : 0:00:41.326000
>>>> Running covoar for score
>>>> covoar results directory:
>>>> /home/cpod/development/rtems/leon3/coverage/score
>>>> ERROR: executable build prefix does not match: sparc-rtems5
>>>> ***Cleaning tempfiles***
>>>> error: covoar failure exit code: 1
>>>>
>>>> Not sure how thats related.
>>>>
>>>> Its checking
>>>>
>>>>  if (buildPrefix.empty()) {
>>>>
>>>>  76           buildPrefix = *pri;
>>>>
>>>>  77         } else {
>>>>
>>>>  78           if (buildPrefix != *pri) {
>>>>
>>>>  79             std::cout << "buildBSP: " + buildBSP << "\n*pri: " +
>>>> *pri << std::en
>>>>     dl;
>>>>  80             fail = "executable build prefix does not match: " +
>>>> buildPrefix;
>>>>  81             break;
>>>>
>>>>  82           }
>>>>
>>>>  83         }
>>>>
>>>> I added those checks, Its stepping back through the path and checking
>>>> if each directory makes sense. It seems to be out of line now
>>>>
>>>> ERROR: executable build prefix does not match: sparc-rtems5
>>>> buildBSP: leon3
>>>> *pri: sparc-rtems5
>>>> ***Cleaning tempfiles***
>>>>
>>> initially there were two problems
>>> +exe.cov and .cov mismatch
>>> +access library from outside the leon3 directory.
>>>
>>> The patch solves the first one, that's one step .
>>> The next step can be solved by adding the path to the build-target ,
>>> i.e. sparc-rtems5 , from HOME directory, you can manually add it and see it
>>> running for now. That tells us that inclusion of the path in more standard
>>> way will solve it.
>>>
>> in score-symbol.ini file
>>
>
> To state it clearly :
>
> I added this to the score-symbol.ini
>
> [score]
>  libraries=/home/lunatic/development/rtems/kernel/leon3/@BUILD-TARGET@
> /c/@BSP@/cpukit/score/libscore.a
>
> and that worked .
> To do it in proper way we can do it from the script by using something
> like the path.abspath() and that will fix this I think.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180513/b0703766/attachment-0002.html>