<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 4, 2018 at 2:12 PM, 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="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 5 June 2018 at 00:31, 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">I will add that covoar was originally designed to generate a report on one<div>set at a time. The iteration over symbol sets was done at the scripting</div><div>level above that. </div><div><br></div><div>This had the advantage of being simple at the time. It may still be simple<br></div><div>but moving the iteration over sets to covoar will probably be faster.</div><div><br></div><div>I think DesiredSymbols is instanced a single time. As a starting point, there</div><div>would have to be multiple instances of this -- one for each symbol set.</div><div><br></div><div>Beyond that, there is a correlation between the report generated and</div><div>the desired symbols set.</div><div><br></div><div>So I am thinking that we need to define a "context" structure for each</div><div>set. One simple thought is that there is one "master/unified" DesiredSymbol</div><div>set under the hood and the symbols in each set are used as a filter </div><div>when generating reports. So process the executables for every symbol</div><div>but generate the report subdirectories based on one of the sets of </div><div>DesiredSymbols.</div><div><br></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I think that should work.</div><div><br></div><div>Cillian.. you have been through the flow. Am I thinking right that it is </div><div><br></div><div>And I think we need to merge before doing this type of work. If we can process</div><div>a single set correctly, that's a baseline. Adding iteration will be easier to review</div><div>as another patch.</div><div> </div></div></blockquote></span><div>we can process a single set correctly.</div><div>Shall we proceed with merging the above patch with the suggested small edits</div><div>and then file a ticket for the iteration and then start working on it ?</div></div></div></div></blockquote><div><br></div><div>Please. </div><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>I am confused with running of coverage for multiple bsp. If a single </div><div>report.html has to show the reports of multiple bsps (as hinted by Cillian)</div><div>Then a lot of rewroking would be needed. If we're headed in that way </div><div>then I think making separate report.html like leon3-report.html would be simpler</div><div>to achieve, and then create a master index.html for listing all the report htmls.</div></div></div></div></blockquote><div><br></div><div>A single run of the tester will test a single BSP. If you open two shell windows</div><div>and run the tester in both, will those collide?</div><div><br></div><div>covoar does not need support internally to process multiple BSPs concurrently. </div><div><br></div><div>It is common practice to build and test multiple BSPs in parallel to take advantage</div><div>of machines with many cores. </div><div><br></div><div>But if you aren't careful, you can't even have two build/test trees at the same time</div><div>if they collide on file names in shared directories. </div><div><br></div><div>Does that make sense?</div><div><br></div><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><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_4484645046860492745HOEnZb"><div class="m_4484645046860492745h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 4, 2018 at 1:43 PM, Cillian O'Donnell <span dir="ltr"><<a href="mailto:cpodonnell8@gmail.com" target="_blank">cpodonnell8@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"><br><div class="gmail_quote"><div><div class="m_4484645046860492745m_126621097641330315h5">On 4 June 2018 at 19:03, 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="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_4484645046860492745m_126621097641330315m_-5912283098791887757h5">On 2 June 2018 at 01:00, 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="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_4484645046860492745m_126621097641330315m_-5912283098791887757m_2765358686929796215h5">On 2 June 2018 at 00:48, 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="auto"><div><div class="m_4484645046860492745m_126621097641330315m_-5912283098791887757m_2765358686929796215m_2359960413011435463h5"><div><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Jun 1, 2018, 11:21 AM Vijay Kumar Banerjee <<a href="mailto:vijaykumar9597@gmail.com" target="_blank">vijaykumar9597@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 class="gmail_extra"><div class="gmail_quote">On 1 June 2018 at 20:30, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" rel="noreferrer" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jun 1, 2018 at 10:28 AM, Vijay Kumar Banerjee<br>
<div><div class="m_4484645046860492745m_126621097641330315m_-5912283098791887757m_2765358686929796215m_2359960413011435463m_-8369820594152722803m_-5676231831902086972h5"><<a href="mailto:vijaykumar9597@gmail.com" rel="noreferrer" target="_blank">vijaykumar9597@gmail.com</a>> wrote:<br>
> On 1 June 2018 at 19:24, Joel Sherrill <<a href="mailto:joel@rtems.org" rel="noreferrer" target="_blank">joel@rtems.org</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Fri, Jun 1, 2018 at 2:46 AM, Vijay Kumar Banerjee<br>
>> <<a href="mailto:vijaykumar9597@gmail.com" rel="noreferrer" target="_blank">vijaykumar9597@gmail.com</a>> wrote:<br>
>>><br>
>>> Here's the list of Ideas for improvements:<br>
>>><br>
>>> 1. Include the section coverage in the bsp config file.<br>
>>> If the section is not found then the script will show<br>
>>> proper error showing coverage is not supported for the<br>
>>> provided bsp config file.<br>
>>><br>
>>> 2. Update covoar to add support for separate coverage report<br>
>>> for each symbol set.<br>
>>><br>
>>> 3. Add a method somewhere in covoar to get the size of an instruction<br>
>>> and fix the hard coded size 4 in ObjdumpProcessor.cc<br>
>><br>
>><br>
>> What about a single XXX_run command? What about that suggestion?<br>
>><br>
> The suggestion was to turn test_run and coverage_run into a single command.<br>
> I have kept them separate so that there's a possibility to just run the<br>
> test.<br>
><br>
> If we want to run coverage everytime we run the test. we can do it.<br>
> Then I think the --coverage option can be changed to --coverage-sets<br>
> to mention the sets.<br>
> If that's what we're looking for then I don't think a separate ticket is<br>
> needed,<br>
> I can try to do it within tomorrow and submit an updated patch.<br>
><br>
>><br>
>> Will there be an update to this patch?<br>
>><br>
> This patch is working an showing results. I don't have any work<br>
> going related to this patch currently.<br>
> If there are any suggestions, I'll try to include all the suggested updates<br>
> as soon as possible and submit. So that we can get it merged.<br>
><br>
<br>
</div></div>I get confused by the similarity between test_run() and coverage_run()<br>
names, and now I'm also seeing some confusion because there is a<br>
function coverage_run() and a class coverage_run. I suggest you remove<br>
this function coverage_run(), and make either coverage_run.__init__()<br>
or coverage_run.run() take the executables as a parameter directly.<br>
<span class="m_4484645046860492745m_126621097641330315m_-5912283098791887757m_2765358686929796215m_2359960413011435463m_-8369820594152722803m_-5676231831902086972HOEnZb"><font color="#888888"><br></font></span></blockquote><div>Thank you for the suggestion. :)</div><div>I have removed the function and taken executables as a parameter in</div><div>coverage_run.__init__() </div><div><br></div><div>I have a question.</div><div>The ini file that is fed to covoar is written by the script according to the</div><div>symbols mentioned by the user. I haven't include the ini file in the patch.</div><div>I'm planning to delete the file after the run, unless --no-clean option is given,</div><div>which currently deletes the .cov trace files after the run.</div></div></div></div></blockquote></div></div><div dir="auto"><br></div></div></div><div dir="auto">That makes sense.</div><span><div dir="auto"><br></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>Can I proceed with this ? </div></div></div></div></blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">Yes.</div></div></blockquote></div></div><div>Added. Thanks. :) </div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span><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>also, shall I include that in the .gitignore ?</div></div></div></div></blockquote></div></div><div dir="auto"><br></div></span><div dir="auto">Is the name of the file constant? The same across multiple BSPs? If so, then this will be a problem doing automated testing of multiple BSPs in parallel.</div><div dir="auto"><br></div></div></blockquote></span><div>The ini file I'm talking about is the symbol sets config file not the bsp</div><div>config file. yes the name is constant. Should it be unique to the bsp ?</div><div>something like, leon3-symbols.ini ?</div><div>How does the automated testing work?</div><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"></div><div dir="auto">I think the name needs to be unique <a href="http://enough.to" target="_blank">enough.to</a> support running testing with coverage on multiple BSPs in parallel. That means you can't add it to gitignore. And can add another issue and FIXME to the code.</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></div></div></div></div></blockquote></div></div></div></blockquote></span><div>If it is needed then I have a fix in mind. I can take the bsp name and add</div><div>'-symbols.ini' to it. and add *-symbols.ini to .gitignore .</div></div></div></div></blockquote></div></div><div>Shall I add this or put a fixme in the code and post a patch ?</div><div>Are there any other suggestions for the patch ?</div><div><br></div><div>I was looking into covoar for generating separate reports for each symbolset.</div><div>Seems like all the coverage reports are generated together and are written</div><div>in the _outputDirectory_ .</div></div></div></div></blockquote><div> </div></div></div><div>The output directory should be aligned with the bsp and the report.html changed to keep record of this instead of searching for the generic coverage dir. Look for leon3-coverage and so on. As well as the symbol-sets.ini change you mentioned above. That would probably be enough to not cause any conflicts with parallel testing (I may be missing a case there, I let you know if anything else comes to mind). The main thing to think about is if multiple bsps are being tested at the same time, they have to know which config file is there's and which output directory and whatever else they may be looking for, the names have to be unique. These things are all fed to covoar so the changes can be added to coverage.py.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> I couldn't figure out how to cleanly address this.</div><div>If covoar is intended to generate reports from multiple subsystems/symbolsets,</div><div>then I think this would be a needed update. Otherwise we can do it from the </div><div>script, by feeding covoar with a single set ini and putting the result in a separate</div><div>directory . </div><span><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>Can we do this ? </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"><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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="m_4484645046860492745m_126621097641330315m_-5912283098791887757m_2765358686929796215m_2359960413011435463m_-8369820594152722803m_-5676231831902086972HOEnZb"><font color="#888888">
-Gedare<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div></div></div>
</blockquote></div><br></div></div>
</blockquote></span></div><br></div></div>
<br></span><span>______________________________<wbr>_________________<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<wbr>/listinfo/devel</a><br></span></blockquote></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>