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

Vijay Kumar Banerjee vijaykumar9597 at gmail.com
Sun May 13 11:39:49 UTC 2018 

On Sun, 13 May 2018, 17:02 Cillian O'Donnell, <cpodonnell8 at gmail.com> wrote:

> 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.
>
from the top of the build tree, it does work if you just manually change
the extension .
But it doesn't building from outside the directory, say from coverage_test
directory . The change I'm suggesting is to make it work from there .
For that we need to take the absolute path of the lib . maybe by
implementing something like realpath() from rld::path will do it.

>
> 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/46a5c67b/attachment-0002.html>

More information about the devel mailing list