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