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

Chris Johns chrisj at rtems.org
Tue Jun 19 00:02:05 UTC 2018


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?

Chruis



More information about the devel mailing list