On 13 May 2018 at 13:47, Vijay Kumar Banerjee <vijaykumar9...@gmail.com>
wrote:
>
> On Sun, 13 May 2018, 18:14 Cillian O'Donnell, <cpodonne...@gmail.com>
> wrote:
>
>>
>>
>> On 13 May 2018 at 13:35, Vijay Kumar Banerjee <vijaykumar9...@gmail.com>
>> wrote:
>>
>>>
>>> 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.
>>>
>>
>> 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 <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
