<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, 19 Jun 2018, 05:32 Chris Johns, <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 16/06/2018 02:55, Vijay Kumar Banerjee wrote:<br>
> On Fri, 15 Jun 2018, 08:39 Chris Johns, <<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a><br>
> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank" rel="noreferrer">chrisj@rtems.org</a>>> wrote:<br>
> On 14/06/2018 03:12, Gedare Bloom wrote:<br>
> > On Wed, Jun 13, 2018 at 12:23 PM, Vijay Kumar Banerjee<br>
> > <<a href="mailto:vijaykumar9597@gmail.com" target="_blank" rel="noreferrer">vijaykumar9597@gmail.com</a> <mailto:<a href="mailto:vijaykumar9597@gmail.com" target="_blank" rel="noreferrer">vijaykumar9597@gmail.com</a>>> wrote:<br>
> >> On Wed, 13 Jun 2018, 21:39 Gedare Bloom, <<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a><br>
> <mailto:<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a>>> wrote:<br>
> >>> On Wed, Jun 13, 2018 at 11:58 AM, Vijay Kumar Banerjee<br>
> >>> <<a href="mailto:vijaykumar9597@gmail.com" target="_blank" rel="noreferrer">vijaykumar9597@gmail.com</a> <mailto:<a href="mailto:vijaykumar9597@gmail.com" target="_blank" rel="noreferrer">vijaykumar9597@gmail.com</a>>> wrote:<br>
> >>>> On 13 June 2018 at 10:29, Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a><br>
> <mailto:<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a>>> wrote:<br>
> >>>>> On Thu, Jun 7, 2018 at 7:08 AM, Vijay Kumar Banerjee<br>
> >>>>> <<a href="mailto:vijaykumar9597@gmail.com" target="_blank" rel="noreferrer">vijaykumar9597@gmail.com</a> <mailto:<a href="mailto:vijaykumar9597@gmail.com" target="_blank" rel="noreferrer">vijaykumar9597@gmail.com</a>>> wrote:<br>
> >>>>>> bsp = opts.find_arg('--rtems-bsp')<br>
> >>>>>> + if 'cov' in bsp[1].split('-'):<br>
> >>>>><br>
> >>>>> I'm not sure if this use of the 'cov' field in the bsp config filename<br>
> >>>>> itself is the proper way to go about accomplishing the activation of<br>
> >>>>> coverage. What are other possible ways to get this done? Is the use of<br>
> >>>>> a portion of the bsp config filename done elsewhere in tester?<br>
> >>>><br>
> >>>> This patch was made following Chris' comments in another thread<br>
> >>>><br>
> >>>> <a href="https://lists.rtems.org/pipermail/devel/2018-June/021931.html" rel="noreferrer noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2018-June/021931.html</a><br>
> <<a href="https://lists.rtems.org/pipermail/devel/2018-June/021931.html" rel="noreferrer noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2018-June/021931.html</a>><br>
> >>>><br>
> >>><br>
> >>> I can't be sure, but I don't think his intent was to infer the<br>
> >>> coverage from the ini file name.<br>
> <br>
> Correct.<br>
> <br>
> >>> For example, does the tester parse<br>
> >>> the ini file name to check for 'qemu' to decide if that target is<br>
> >>> being used? Instead, it should look in to the config file to read the<br>
> >>> option somehow.<br>
> >><br>
> >> In leon3-qemu.ini the bsp option inside the<br>
> >> config file is set to leon3-qemu.<br>
> >><br>
> >> There's no such special thing added to bsp for coverage.<br>
> >> Only difference we have is that,<br>
> >> the option 'bsp_qemu_cov_opts' is added in the coverage supported file. we<br>
> >> can<br>
> >> read the config file to see if this option is present.<br>
> >><br>
> >> Shall I do it this way?<br>
> ><br>
> > Yes, I suspect you should.<br>
> ><br>
> <br>
> Can we have 'coverage = true' in the INI file to indicate this BSP supports<br>
> coverage?<br>
> <br>
> We can do it.<br>
> <br>
> In the other thread, there were discussions on adding a section 'coverage'<br>
> to the ini file, and give all the coverage related options under it.<br>
> <br>
> What do you think of that approach ?<br>
> <br>
<br>
I am not sure at the moment. We have a cov INI file per BSP so it is not clear<br>
to me if we need a separate section.<br>
<br>
I would like to get my 22 patches pushed to master before moving on this topic.<br>
This is the report I generate:<br>
<br>
<a href="https://ftp.rtems.org/pub/rtems/people/chrisj/coverage/leon3/leon3-qemu-report.html" rel="noreferrer noreferrer" target="_blank">https://ftp.rtems.org/pub/rtems/people/chrisj/coverage/leon3/leon3-qemu-report.html</a><br>
<br>
How does this look?<br></blockquote></div></div><div dir="auto">The report looks good.</div><div dir="auto">This report is from two subsystems score and rtems</div><div dir="auto">that are mentioned in the symbols ini file.</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"><br>
Chruis<br>
</blockquote></div></div></div>