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

Cillian O'Donnell cpodonnell8 at gmail.com
Sun May 13 12:02:21 UTC 2018


I understand but that's a separate issue. I can do a full coverage run from
the top of the build tree by changing hello.exe.cov to hello.cov manually
using current master. Then I add your patch which is supposed to fix the
problem of having to change those manually so it looks for hello.exe.cov
instead but I can't even make it to the point of doing the coverage runs
anymore so it must of  had some unintended consequences.

I know its frustrating to work on a problem for a while and you finally
come up with the solution only to have all of us complain that it's not
quite right but that's just collaborative development, you'll have to get
used to it :)...

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

>
>
> 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/a0710d3b/attachment.html>


More information about the devel mailing list