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?
> 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
