<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, 26 Jan 2019 at 01:46, Joel Sherrill <<a href="mailto:joel@rtems.org">joel@rtems.org</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 dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail-m_-4537736548042766270gmail_attr">On Fri, Jan 25, 2019 at 12:50 PM Vijay Kumar Banerjee <<a href="mailto:vijaykumar9597@gmail.com" 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="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail-m_-4537736548042766270gmail-m_-1328431271889010107m_-3923994691692435842m_-4467783729698275861gmail_attr">On Fri, 25 Jan 2019 at 23:39, Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</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 dir="ltr">Sorry for the duplicate email. I didn't use the right email address and the response did not go to devel@</div><br><div class="gmail_quote"><div dir="ltr" class="gmail-m_-4537736548042766270gmail-m_-1328431271889010107m_-3923994691692435842m_-4467783729698275861gmail-m_5342623143963802186gmail_attr">On Fri, Jan 25, 2019 at 8:43 AM Jiri Gaisler <<a href="mailto:jiri@gaisler.se" target="_blank">jiri@gaisler.se</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 bgcolor="#FFFFFF">
<p>Sorry for the noise, but I have a better patch that actually solves the root problem. I ran the full testsuite on sis and covoar against libscore.a like this:</p>
<p style="margin:0px;text-indent:0px">$ sparc-rtems5-ar -rcs sparc-rtems5/c/leon3/cpukit/score/libscore.a sparc-rtems5/c/leon3/cpukit/score/src/*.o</p>
<p></p>
<p>$ rtems-test --rtems-bsp=leon3-sis-cov sparc-rtems5/c/leon3/testsuites</p>
<p>$ /opt/rtems/5/share/rtems/tester/bin/covoar -v -f TSIM -S /opt/rtems/5/share/rtems/tester/rtems/testing/coverage/score-symbols.ini -O coverage -E /opt/rtems/5/share/rtems/tester/rtems/testing/coverage/Explanations.txt -p RTEMS-5 sparc-rtems5/c/leon3/testsuites/*/*.exe</p>
<p>summary.txt:</p>
<p>Bytes Analyzed : 39376 Bytes Not Executed : 2864 Percentage Executed : 92.73 Percentage Not Executed : 7.273 Uncovered ranges found : 108 Total branches found : 860 Uncovered branches found : 200 61 branches always taken 139 branches never taken</p>
<p>All symbol sizes and ranges are now correctly reported/calculated in the reports. There are two remaining issues to be solved:</p>
<p>1. File names are printed as 'unknown' in reports (minor problem but useful)</p></div></blockquote><div>Originally we got the info via the binutils command line tools. I think the </div><div>filename came from addr2line. When we designed it originally, Ian Lance</div><div>Taylor said parsing the tool output was more easier, reliable, and more </div><div>stable than tracking any elf reading library.</div><div><br></div><div>But it was slower than accessing the data directly via ELF and DWARF.</div><div>Since Chris added this support for the dynamic loader, it was natural to</div><div>begin to replace that code. Unfortunately, there are some warts left from</div><div>the transition. The name may be one of them.</div><div><br></div><div>We also think the beginning and end of a method are not marked properly.</div><div><br></div><div>And when something is inlined, it isn't considered part of the main method.</div><div>The original method considered assembly from inlined code part of the</div><div>caller. It is now reported as part of the callee. We have identified a needed</div><div>change to (1) account for the inlined assembly as part of the caller and</div><div>(2) add additional tracking of the coverage of inlined methods.</div><div><br></div><div>The immediate need is to get the reporting so it accurately annoates</div><div>the generated assembly from a method and anything inlined into it.</div><div>This should let us do DO-178 Level A style coverage -- we are</div><div>sure we use ever instruction and take/not take every branch.</div><div><br></div></div></div></blockquote><div>Hello, </div><div>This is awesome to have the sis support in covoar, the very next thing that </div><div>comes to my mind is adding the '-f' option in the rtems-test coverage script,</div><div>this will enable us to get the HTML reports.</div><div><br></div><div>The issues noted here, can make a very good project for GSoC and I was </div><div>hoping to work on them, but there is a good amount of complexity involved, </div><div>and I am confused where to get started. :) </div></div></div></blockquote><div><br></div><div>This should be another thread but here's a short answer</div><div><br></div><div>+ Verify Jiri didn't break reporting from qemu testing<br></div><div><br></div></div></div></blockquote><div> Reporting from qemu works properly with the patch. Checked with rtems-test</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 class="gmail_quote"><div></div><div>Then I recall a few odd problems:</div><div><br></div><div>+ method entry and exit not being marked as executed even though<br></div><div>we know it was.</div><div>+ inlined code not being marked because it wasn't reported as<br></div><div>"in the method"</div><div><br></div><div>If all reports look trustworthy, then look into additionally tracking</div><div>coverage of inlined methods but track it back to their source.</div><div> </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 class="gmail_quote"><div><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 class="gmail_quote"><div></div><div>If there is unreachable code or branches where both paths are not</div><div>exercised, we need tests to exercise them OR the code is useless</div><div>and can be removed. Either way, we win. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
<p>2. We should add RISC-V support to covoar ...</p></div></blockquote><div><br></div><div>I am sure you have seen the Target* files. They are not large. Some is</div><div>trivial. Other parts are to recognize nops and branch instruction </div><div>variants. </div><br class="gmail-m_-4537736548042766270gmail-m_-1328431271889010107m_-3923994691692435842m_-4467783729698275861gmail-m_5342623143963802186gmail-Apple-interchange-newline"></div></div></blockquote><div>Is the workflow something like this ...</div><div>1. write Target_ARCH.cc</div><div>2. Add it to the TargetFactory</div><div>3. Add ini file in the tools .</div><div><br></div><div>I have a question. Is there some reason that the files in covoar/ don't have a </div><div>copyright notice? </div></div></div></blockquote><div><br></div><div>Sloppiness. :(</div><div><br></div><div>The original code was written entirely by OAR. We could probably use git</div><div>blame to augment that.</div><div> </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 class="gmail_quote"><div><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 class="gmail_quote"><div> On a RISC architecture, I wouldn't expect a lot of variation in nops.</div><div>The x86 has an awful set that range in size. :(</div><div><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 bgcolor="#FFFFFF">
<p>
</p>Let me know if you agree to the patch ..<br></div></blockquote><div><br></div><div>The patch looks good to me. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
</div>_______________________________________________<br>devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div></div></div>