Gcov support in Covoar

[Vijay Kumar Banerjee]

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>

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/20180705/b1fb6ce8/attachment-0002.html>