On Sun, 13 May 2018, 17:32 Cillian O'Donnell, <cpodonne...@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.
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 <vijaykumar9...@gmail.com>
> wrote:
>
>>
>>
>> On Sun, 13 May 2018, 17:02 Cillian O'Donnell, <cpodonne...@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 <vijaykumar9...@gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 13 May 2018 at 16:16, Vijay Kumar Banerjee <vijaykumar9...@gmail.com
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, 13 May 2018, 16:15 Vijay Kumar Banerjee, <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, 13 May 2018, 16:09 Cillian O'Donnell, <cpodonne...@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.
>>>>
>>>>
>>>>
>>>
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
