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

Vijay Kumar Banerjee vijaykumar9597 at gmail.com
Sun May 13 12:47:11 UTC 2018 

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

>
>
> On 13 May 2018 at 13:35, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
> wrote:
>
>>
>> On Sun, 13 May 2018, 17:32 Cillian O'Donnell, <cpodonnell8 at gmail.com>
>> wrote:
>>
>>> 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.
>>>
>>
>> it's building fine here.
>>
>
> Does it only work if you change the path in the ini file?
>
if you're running from the top of leon3 build tree then Changing the path
shouldn't be required.

>
>
>> have you tried ./waf build install after the changes to covoar.cc?
>>
>> can you please try the v2 of the patch, ./waf build install it and see if
>> it's behaving the same ?
>>
>>
>>> 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 :)...
>>>
>> That's alright. :)
>>
>>>
>>> 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/8177a758/attachment-0002.html>

More information about the devel mailing list