<div dir="ltr"><div><div>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.<br><br></div>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 :)...<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 May 2018 at 12:39, Vijay Kumar Banerjee <span dir="ltr"><<a href="mailto:vijaykumar9597@gmail.com" target="_blank">vijaykumar9597@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div><br><br><div class="gmail_quote"><div dir="ltr">On Sun, 13 May 2018, 17:02 Cillian O'Donnell, <<a href="mailto:cpodonnell8@gmail.com" target="_blank">cpodonnell8@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div></div></blockquote></div></div></span><div dir="auto">from the top of the build tree, it does work if you just manually change the extension .</div><div dir="auto">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 .</div><div dir="auto">For that we need to take the absolute path of the lib . maybe by implementing something like realpath() from rld::path will do it.</div><div><div class="h5"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br>warning: Unable to read coverage file: /home/cpod/development/rtems/<wbr>leon3/sparc-rtems5/c/leon3/<wbr>testsuites/samples/unlimited/<wbr>unlimited.cov<br>Processing multiple executable/coverage file pairs<br>Coverage Format : html<br>Target : sparc-rtems5<br><br>Coverage file /home/cpod/development/rtems/<wbr>leon3/sparc-rtems5/c/leon3/<wbr>testsuites/samples/hello/<wbr>hello.cov for executable: /home/cpod/development/rtems/<wbr>leon3/sparc-rtems5/c/leon3/<wbr>testsuites/samples/hello/<wbr>hello.exe<br>Loading symbol sets: /home/cpod/development/rtems/<wbr>test/rtems-tools/tester/rtems/<wbr>testing/coverage/score-<wbr>symbols.ini<br> Symbol set: score<br> Loading library: sparc-rtems5/c/leon3/cpukit/<wbr>score/libscore.a<br>Analyzing 382 symbols<br>Extracting information from: /home/cpod/development/rtems/<wbr>leon3/sparc-rtems5/c/leon3/<wbr>testsuites/samples/hello/<wbr>hello.exe<br>Created unified coverage map for _RTEMS_Lock_allocator (0x0 - 0x13)<br>Created unified coverage map for _RTEMS_Unlock_allocator (0x0 - 0x13)<br>Created unified coverage map for _API_Mutex_Lock (0x0 - 0x2f)<br>..............<br>Processing coverage file /home/cpod/development/rtems/<wbr>leon3/sparc-rtems5/c/leon3/<wbr>testsuites/samples/hello/<wbr>hello.cov for executable /home/cpod/development/rtems/<wbr>leon3/sparc-rtems5/c/leon3/<wbr>testsuites/samples/hello/<wbr>hello.exe<br>Preprocess uncovered ranges and branches<br>Computing uncovered ranges and branches<br>Branch always taken found in _API_Mutex_Lock (0x40005f98 - 0x40005f9b)<br>Branch always taken found in _API_Mutex_Unlock (0x40005fc0 - 0x40005fc3)<br>Branch never taken found in _Chain_Initialize (0x4000600c - 0x4000600f)<br>Branch always taken found in _Freechain_Get (0x40006070 - 0x40006073)<br>Branch never taken found in _Freechain_Get (0x40006084 - 0x40006087)<br>Branch never taken found in _Heap_Allocate_aligned_with_<wbr>boundary (0x40006108 - 0x4000610b)<br>........................<br>Calculate statistics<br>Looking up source lines for uncovered ranges and branches<br>Looking up source lines for uncovered ranges in CSWTCH.1<br>Looking up source lines for uncovered branches in _API_Mutex_Lock<br>Looking up source lines for uncovered ranges in _API_Mutex_Unlock<br>Looking up source lines for uncovered branches in _API_Mutex_Unlock<br>Looking up source lines for uncovered branches in _Chain_Initialize<br>Looking up source lines for uncovered ranges in _Freechain_Get<br>............................<br>Generate Reports<br>Generate index.txt<br>Generate annotated.txt<br>Generate branch.txt<br>Generate uncovered.txt<br>Generate sizes.txt<br>Generate symbolSummary.txt<br>Generate index.html<br>Generate annotated.html<br>Generate branch.html<br>Generate uncovered.html<br>Generate sizes.html<br>Generate symbolSummary.html<br>Writing Not Found Report (/home/cpod/development/rtems/<wbr>leon3/coverage/score/<wbr>ExplanationsNotFound.txt)<br>Coverage run for score finished successfully.<br>------------------------------<wbr>-----------------<br>Generating reports<br>Coverage analysis finished. You can find results in /home/cpod/development/rtems/<wbr>leon3<br>***Cleaning tempfiles***<br><br></div>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.<br><div><br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 May 2018 at 12:07, Vijay Kumar Banerjee <span dir="ltr"><<a href="mailto:vijaykumar9597@gmail.com" rel="noreferrer" target="_blank">vijaykumar9597@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><div><div class="m_-5237382130292940676m_8736370319797108271h5"><br clear="all"><div><div class="m_-5237382130292940676m_8736370319797108271m_-6111152075631911055gmail_signature"><div dir="ltr"><div dir="ltr">On 13 May 2018 at 16:16, Vijay Kumar Banerjee <span dir="ltr"><<a href="mailto:vijaykumar9597@gmail.com" rel="noreferrer" target="_blank">vijaykumar9597@gmail.com</a>></span> wrote:<br></div></div></div></div></div></div><div class="gmail_quote"><div><div class="m_-5237382130292940676m_8736370319797108271h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="m_-5237382130292940676m_8736370319797108271m_-6111152075631911055gmail-h5"><div><br><br><div class="gmail_quote"><div dir="ltr">On Sun, 13 May 2018, 16:15 Vijay Kumar Banerjee, <<a href="mailto:vijaykumar9597@gmail.com" rel="noreferrer" target="_blank">vijaykumar9597@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Sun, 13 May 2018, 16:09 Cillian O'Donnell, <<a href="mailto:cpodonnell8@gmail.com" rel="noreferrer noreferrer" target="_blank">cpodonnell8@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>It does seem to be having some knock on effect. Covoar made it past these checks before.<br><br>-----------------<br>Total: 13<br>Average test time: 0:00:03.178923<br>Testing time : 0:00:41.326000<br>Running covoar for score<br>covoar results directory:<br>/home/cpod/development/rtems/<wbr>leon3/coverage/score<br>ERROR: executable build prefix does not match: sparc-rtems5<br>***Cleaning tempfiles***<br>error: covoar failure exit code: 1<br><br></div>Not sure how thats related.<br><br></div>Its checking<br><br> if (buildPrefix.empty()) { <wbr> <br> 76 buildPrefix = *pri; <wbr> <br> 77 } else { <wbr> <wbr> <br> 78 if (buildPrefix != *pri) { <wbr> <br> 79 std::cout << "buildBSP: " + buildBSP << "\n*pri: " + *pri << std::en<br> dl;<br> 80 fail = "executable build prefix does not match: " + buildPrefix; <br> 81 break; <wbr> <wbr> <br> 82 } <wbr> <wbr> <br> 83 } <br><br></div>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<br><br>ERROR: executable build prefix does not match: sparc-rtems5<br>buildBSP: leon3<br>*pri: sparc-rtems5<br>***Cleaning tempfiles***<br></div></div></blockquote></div></div><div dir="auto">initially there were two problems </div><div dir="auto">+exe.cov and .cov mismatch</div><div dir="auto">+access library from outside the leon3 directory. </div><div dir="auto"><br></div><div dir="auto">The patch solves the first one, that's one step .</div><div dir="auto">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.</div></div></blockquote></div></div></div></div><div dir="auto">in score-symbol.ini file</div></div></blockquote><div><br></div></div></div><div>To state it clearly :</div><div><br></div><div>I added this to the score-symbol.ini</div><div><br></div><div>[score]</div><div> libraries=/home/lunatic/<wbr>development/rtems/kernel/<wbr>leon3/@BUILD-TARGET@/c/@BSP@/<wbr>cpukit/score/libscore.a</div><div><br></div><div>and that worked .</div><div>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.<br></div><div> </div></div><br></div></div>
</blockquote></div><br></div>
</blockquote></div></div></div></div></div>
</blockquote></div><br></div>