[PATCH v2 2/2] coverage/symbol-sets.ini : Add symbol-sets and paths to respective libraries

Cillian O'Donnell cpodonnell8 at gmail.com
Thu Jul 26 17:59:05 UTC 2018


On Thu, 26 Jul 2018, 18:51 Vijay Kumar Banerjee, <vijaykumar9597 at gmail.com>
wrote:

>
>
> On Thu, Jul 26, 2018, 10:34 PM Cillian O'Donnell <cpodonnell8 at gmail.com>
> wrote:
>
>> Kryzstof is the original author, so his name should probably stick. You
>> could add lines for
>>
>> Reviewed by: Vijay on date: ...
>>
>> I think that's standard enough
>>
>> All the best,
>>
>> Cillian
>>
> Thanks for the reply and for all the help
> throughout the summer. It was a great
> experience !!
>

I'm glad you enjoyed it! Sorry I was so quiet over gcov phase, I just don't
much about it and couldn't seem to catch up.

It's a great achievement to make through gsoc. Many are called, but few are
chosen... and even fewer can finish..:) Well done!

>
>>> On Thu, 26 Jul 2018, 17:22 Vijay Kumar Banerjee, <
>> vijaykumar9597 at gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I have a question which I forgot to ask before.
>>> Should the coverage.py and symbol-sets.ini files have mine and/or
>>> Cillian's name
>>> included in the copyright notice?
>>>
>>> --vijayk
>>> On 26 July 2018 at 13:09, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com
>>> > wrote:
>>>
>>>> I have added all the libs in cpukit and commented them out.
>>>> Please have a look at the attached file.
>>>>
>>>> On 26 July 2018 at 04:50, Joel Sherrill <joel at rtems.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 25, 2018 at 10:41 AM, Vijay Kumar Banerjee <
>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>
>>>>>> ---
>>>>>>  tester/rtems/testing/coverage/symbol-sets.ini | 11 ++++++++---
>>>>>>  1 file changed, 8 insertions(+), 3 deletions(-)
>>>>>>
>>>>>> diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
>>>>>> b/tester/rtems/testing/coverage/symbol-sets.ini
>>>>>> index a2ec7bc..3900f14 100644
>>>>>> --- a/tester/rtems/testing/coverage/symbol-sets.ini
>>>>>> +++ b/tester/rtems/testing/coverage/symbol-sets.ini
>>>>>> @@ -29,8 +29,13 @@
>>>>>>  #
>>>>>>
>>>>>>  [symbol-sets]
>>>>>> -sets = score,rtems
>>>>>> +sets = score,rtems,libblock,libcrypt,libcsupport,libmd,libnetworking
>>>>>>
>>>>>>  [libraries]
>>>>>> -score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>>>>>> -rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>>>>>> +score         = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>>>>>> +rtems         = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>>>>>> +libblock      = @BUILD-TARGET@/c/@BSP@/cpukit/libblock/libblock.a
>>>>>> +libcrypt      = @BUILD-TARGET@/c/@BSP@/cpukit/libcrypt/libcrypt.a
>>>>>> +libcsupport   = @BUILD-TARGET@/c/@BSP@
>>>>>> /cpukit/libcsupport/libcsupport.a
>>>>>> +libmd         = @BUILD-TARGET@/c/@BSP@/cpukit/libmd/libmd.a
>>>>>> +libnetworking = @BUILD-TARGET@/c/@BSP@
>>>>>> /cpukit/libnetworking/libnetworking.a
>>>>>>
>>>>>
>>>>> To be at parity with the old reports but reported on finer
>>>>> granularity,
>>>>> follow the list at
>>>>>
>>>>>
>>>>> https://git.rtems.org/rtems-testing/tree/rtems-coverage/do_coverage#n507
>>>>>
>>>>> and check what is not listed there that is in cpukit now.  For
>>>>> example, jffs2
>>>>> isn't listed in the above. But the things consciously skipped have a
>>>>> good
>>>>> reason. Add a list of the ones not included. It may make sense to
>>>>> have something like this for the ones deliberately skipped:
>>>>>
>>>>> # librpc = @....libXXX.a
>>>>>
>>>>> It will make auditing what's in the cpukit versus the ini file easier.
>>>>> That's why my old script has them in order and commented out the
>>>>> ones we were not ready to do or never would.
>>>>>
>>>>> But for sure, add posix, sapi, libdl, individual filesystem, and catch
>>>>> the libmisc subdirectories listed in the old script for inclusion. for
>>>>> new
>>>>> libmisc content, we can make a decision.
>>>>>
>>>>> Don't include libnetworking. As a general rule, we don't do coverage
>>>>> testing
>>>>> on networking or any  (complex) third party software.
>>>>>
>>>>> I don't think dtc will get coverage either.
>>>>>
>>>>> That should get us closer. I expect you will find some libraries
>>>>> to ask questions on. :)
>>>>>
>>>>> --joel
>>>>>
>>>>>
>>>>>> --
>>>>>> 2.14.4
>>>>>>
>>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180726/cd58007e/attachment-0002.html>


More information about the devel mailing list