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

Cillian O'Donnell cpodonnell8 at gmail.com
Sun May 13 13:30:12 UTC 2018 

Is there supposed to be a message there?

Anyway just to clear this up, try this for me.

1. Grab a new branch of

https://github.com/cillianodonnell/rtems-tools/tree/tester-support

which is the current master plus one patch with the tester support in
progress.

2. Apply your patch to that and make no other changes.

3. Build covoar again.

3. Run the tester from the top of the build tree and tell me what you see.

cpod at cpod ~/development/rtems/leon3 $
$HOME/development/rtems/test/rtems-tools/tester/rtems-test
--rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
--rtems-bsp=leon3-qemu-cov --coverage
$HOME/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples



On 13 May 2018 at 13:58, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
wrote:

>
>
> 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/a1042223/attachment-0002.html>

More information about the devel mailing list