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

Vijay Kumar Banerjee vijaykumar9597 at gmail.com
Sun May 13 12:58:24 UTC 2018 

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

>
>
> On 13 May 2018 at 13:47, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
> wrote:
>
>>
>> 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.
>>
>
> I'm not but did you add the line to leon3-qemu-cov.ini that you mentioned
> above and that's the reason it's working for you. If you change that back
> to the original. Is is still working?
>
>>
>>>
>>>> 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/1a5cf204/attachment-0002.html>

More information about the devel mailing list