[PATCH] coverage : Add support to run coverage in supported bsp without extra options

Vijay Kumar Banerjee vijaykumar9597 at gmail.com
Tue Jun 19 03:16:32 UTC 2018


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>


More information about the devel mailing list