Gcov support in Covoar

[Joel Sherrill]

On Wed, Jul 4, 2018, 1:46 PM Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
wrote:

> On 4 July 2018 at 22:37, Joel Sherrill <joel at rtems.org> wrote:
>
>>
>>
>> On Wed, Jul 4, 2018, 3:06 AM Chris Johns <chrisj at rtems.org> wrote:
>>
>>>
>>>
>>> On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote:
>>> > On 4 July 2018 at 13:09, Chris Johns <chrisj at rtems.org
>>> > <mailto:chrisj at rtems.org>> wrote:
>>> >
>>> >     On 4/7/18 5:38 pm, Chris Johns wrote:
>>> >     > On 4/7/18 4:52 pm, Vijay Kumar Banerjee wrote:
>>> >     >>
>>> >     >> I'm starting this thread for discussions on the gcov support
>>> >     >> in covoar.
>>> >     >>
>>> >     >> Current status is that the code in it (like in GcovData.cc)
>>> remained untouched
>>> >     >> for a long time and it had not been updated after the source
>>> tree reorganization
>>> >     >> which is why it runs into segmentation
>>> >     >> fault while trying to find the source files.
>>> >     >>
>>> >     >> Joel was suggesting to copy the file gcov-io.h from the gcc
>>> >     >> source after a license discussion here.
>>> >     >
>>> >     > What license the file's license?
>>> >
>>> >     Sorry .. What is the file's license?
>>> >
>>> > GPL version 3
>>>
>>> This license is not suitable.
>>>
>>
>> It has the runtime exception and is the only file that defines the format
>> of gcno and (need to double-check) gcda file. It does not contaminate
>> anything.
>>
>> I don't see anyway to interpret gcno or write gcda data otherwise.
>>
>> How does llvm address this? Don't that have the same issue?
>>
>> llvm defines it in GCOV.h file in llvm/ProfileData/ under the license
> it's mentioned there that it's distributed under University of Illinois
> Open Source License
>
> https://github.com/llvm-mirror/llvm/blob/master/include/llvm/ProfileData/GCOV.h
> <https://github.com/llvm-mirror/llvm/blob/master/include/llvm/ProfileData/GCOV.h>
>

That would be the preferred way to get this header. Is it technically
acceptable?

Chris.. license acceptable to you?

>
> Ultimately we have two file formats that we have to deal with that GCC for
>> sure defines and llvm might also.
>>
>>
>>> >     > We are aiming to have all code under the RTEMS Tools under a BSD
>>> or compatible
>>> >     > license. Are there other options that have a more suitable
>>> license?
>>>
>>
>> Llvm would be the only option but this has the rules time exception like
>> the RTEMS historical license so it non-viral.
>>
>> A hack would be to ensure they are installed with the RTEMS GCC by the
>> RSB. But that would be lifting a file out of the GCC source and  one from
>> the build tree that are normally not installed. We could ask about GCC
>> doing that.
>>
>> >     >
>>> >     > Also, could you please explain how gcov fits into the coverage
>>> testing?
>>> >     >
>>> >
>>> > gcov is a test coverage program by gcc that generates
>>> statement-by-statement
>>> > profiling.
>>> > (https://gcc.gnu.org/onlinedocs/gcc/Gcov-Intro.html)
>>>
>>> Yes.
>>>
>>> > once we're able to generate gcov reports we can run graphical tools
>>> like lcov or
>>> > gcovr to generate html and xml reports with detailed coverage data.
>>> > an example of lcov report:
>>> >
>>> http://ltp.sourceforge.net/coverage/lcov/output/example/methods/iterate.c.gcov.html
>>> >
>>>
>>> Do you want to export gcov files from the other trace formats we handle?
>>>
>>
>> Gcov reads gcda files for execution information. Rather than the
>> executable being instrumented and writing this during execution (libgcov),
>> covoar generates gcda files for unmodified executables using simulator
>> trace information. But you have to read gcno files and write gcda files.
>>
>>
>>
>>> How does this fit into the RTEMS Tester tool?
>>>
>>
>> If you want to run gcov or lcov on uninstrumented executables, then
>> covoar has to read gcno and write gcda files. And we have to then run gcov
>> or lcov as normal.
>>
>> It is the path to another report format.
>>
>>>
>>> Chris
>>> _______________________________________________
>>> 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/20180704/3d27c78b/attachment-0002.html>