<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 30 May 2018 at 00:54, Joel Sherrill <span dir="ltr"><<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</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"><br><div class="gmail_quote"><div><div class="h5">On Tue, May 29, 2018 at 11:27 AM, 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"><div><div class="m_-3428551052562069971h5"><div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 29 May 2018, 20:10 Joel Sherrill, <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</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"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 28, 2018 at 11:08 PM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" rel="noreferrer" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 29/5/18 4:26 am, Joel Sherrill wrote:<br>
> On Mon, May 28, 2018 at 5:43 AM, Vijay Kumar Banerjee <<a href="mailto:vijaykumar9597@gmail.com" rel="noreferrer" target="_blank">vijaykumar9597@gmail.com</a><br>
</span><span>> <mailto:<a href="mailto:vijaykumar9597@gmail.com" rel="noreferrer" target="_blank">vijaykumar9597@gmail.c<wbr>om</a>>> wrote:<br>
> <br>
> Hello,<br>
> <br>
> The coverage reports are now showing results.<br>
> The current branch that holds all the changes is<br>
> the cov-tester-support branch in my forked repo<br>
> <br>
> <a href="https://github.com/thelunatic/rtems-tools/tree/cov-tester-support" rel="noreferrer noreferrer" target="_blank">https://github.com/thelunatic<wbr>/rtems-tools/tree/cov-tester-<wbr>support</a><br>
> <<a href="https://github.com/thelunatic/rtems-tools/tree/cov-tester-support" rel="noreferrer noreferrer" target="_blank">https://github.com/thelunati<wbr>c/rtems-tools/tree/cov-tester-<wbr>support</a>><br>
> <br>
> (Please have a look into the code and test it.)<br>
> <br>
> It is close to merging (hopefully). These are the issues<br>
> that would need a fix before it can be merged :<br>
> <br>
> 1. I have added some #FIXME in the code (have a look)<br>
> in coverage script. I have set the value of the targe to be <br>
> sparc-rtems5, which makes it limited to sparc-rtems5 only. We can<br>
> include the target in the bsp ini file, That would<br>
> be a quick fix for this.<br>
> <br>
> <br>
> Yes. This needs to be fixed.<br>
> <br>
> My hack to add 4 in ObjdumpProcessor.cc needs to be addressed also.<br>
> I am thinking of adding a method to Target_*.cc to ask for the size of an<br>
> instruction.<br>
> Then pass it the last instruction. That way we can throw on other architectures for<br>
> now. If Chris solves this with his changes before we try another architecture,<br>
> great. <br>
> If not, it will be easy to fix.<br>
<br>
</span>What is the overall requirement?<br></blockquote><div><br></div><div>To know the ending address of the function. </div><div><br></div><div>Technically there are three pieces of information:</div><div><br></div><div>+ start address </div><div>+ end address</div><div>+ size</div><div><br></div><div>If you know two of those, you can compute the third.</div><div><br></div><div>I don't care if this comes from DWARF, ELF, or parsing the disassembly.</div><div>It just needs to be reliable.</div><div><br></div><div>And.. I am not proposing my solution as permanent. Just to keep us</div><div>moving. You want to change to an internal disassembler (which</div><div>would also need to have the source interspersed) and DWARF. So</div><div>this code would go away then.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What defines the function and so size are attempting to get coverage of? What if<br>
that function calls an inline function and that function is inlined? What if<br>
that inlined function calls another inlined function?<br></blockquote><div><br></div><div>Then it is all inlined. It is done consistently now. I have never seen a case</div><div>where two instances of a method differed as the assembly level. [1]</div><div><br></div><div>The actual body of the inlined method is evaluated at each expansion point.</div><div>That is why a few years ago, I pushed hard to reduce the complexity of</div><div>inline methods because we got test patch explosion when an inlined method</div><div>included complex conditionals.</div><div><br></div><div>Similarly, I think it would be helpful to coverage and verification efforts to</div><div>follow the **shudder** MISRA rule which want you to write simple conditional</div><div>expressions rather than compound ones. I have taken to writing code this</div><div>way as much as possible. But haven't pushed it as a coding rule. </div><div><br></div><div> if (a) {</div><div> if (b) {</div><div> do x;</div><div> }</div><div> }</div><div><br></div><div>Versus</div><div> if (a && b) {</div><div> do x;</div><div> }</div><div><br></div><div>The reason is that the first is easier to analyse coverage on.</div><div><br></div><div>[1] We both expect LTO could change this.</div><div><br></div><div>[2] ESA did specifically mention this one though. Also in general terms,</div><div>an RTEMS Project response to MISRA rules. Which ones we follow, </div><div>reject, etc.. But I refuse to adopt hard rules which can't be enforced</div><div>by free open source tools.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The DWARF data provides details about the PC low and PC high of what is called<br>
concrete functions and then it provides the details about inlines.<br></blockquote><div><br></div><div>We don't (currently) report on the inlines as independent methods. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="m_-3428551052562069971m_-1622777866466922005m_-4285786844237897798h5"><br>
> <br>
> 2. coverage used to feed ini file for each symbol to covoar <br>
> in a loop and store the result in a separate directory<br>
> for each symbol . Which is needed no more needed as<br>
> covoar can now process multi sets from a <br>
> single ini file. I think the results from covoar should be<br>
> store in a separate directory for each symbol<br>
> example :- score/<br>
> <br>
> <br>
> A bit of history will help here. Originally covoar was run against a single set of<br>
> code by the scripting framework. We would do coverage on either "core parts"<br>
> or "developmental" (e.g. nearly all non-networked code). The optimization was<br>
> either at -O2 or -Os. So there were four coverage variants. <br>
> <br>
> Turned out that when we added something to "all", the percentage would drop<br>
> and reflect badly on the rest of the code. I remember adding the dosfs and <br>
> the coverage dropped almost 20 percent.<br>
> <br>
> This led to the idea that we should report on a per directory/subsystem basis.<br>
> The score, rtems, posix, sapi, and libcsupport should have high coverage now<br>
> and the reports should reflect that independent of whether the dosfs needs a <br>
> lot more tests.<br>
> <br>
> Before each directory/subsystem required a completely separate run of covoar.<br>
> If we are headed to a solution where one analysis run of covoar generates different<br>
> reports, that should speed up the processing time a lot!<br>
> <br>
> The other issue is what should the top directory look like/contain when a single<br>
> run produces multiple subsystem reports. Seems like we would need at least a<br>
> top level html and text file.<br>
> <br>
> <br>
> <br>
> 3. currently we are using the leon3-qemu-cov as the bsp.<br>
> Are we going to have two ini file for each bsp ? ( one without coverage<br>
> and one with coverage support)<br>
> <br>
> Earlier the approach was to include a section 'coverage' <br>
> to the bsp ini to put the values we needed for coverage.<br>
> I think that approach would be more "convenient" for the user.<br>
> <br>
> <br>
> This was something Chris suggested. I think it was to avoid adding to<br>
> the bsp ini file until the code was closer to merging.<br>
> <br>
> Chris.. what do you think? Long term, a section would be nice. <br>
> <br>
<br>
</div></div>Sorry I cannot remember without looking it up and I am currently buried in<br>
family issues.<br></blockquote><div><br></div><div>OK. Having the Python scripting loop over the sets or covoar looping over them</div><div>is an open issue. Historically, looping over desired symbol sets was outside</div><div>covoar. So looping inside covoar may take some work.</div><div></div></div></div></div></blockquote></div></div><div dir="auto"><br></div></div></div><div dir="auto">covoar can already loop over the </div><div dir="auto">sets it seems, which is implemented</div><div dir="auto">in DesiredSymbols. But it stores all the </div><div dir="auto">reports generated from into the same directory.</div></div></blockquote><div><br></div></div></div><div>If there is an index that makes its possible to navigate through the</div><div>different "subsystems", then that's the key thing. You don't want</div><div>to think score is poorly covered due to dosfs.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">P.S:Sorry for the previous mail with no message</div><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 class="gmail_extra"><div class="gmail_quote"><div><br></div><div>--joel</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="m_-3428551052562069971m_-1622777866466922005m_-4285786844237897798HOEnZb"><font color="#888888"><br>
Chris<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>