On 4 July 2018 at 22:37, Joel Sherrill <j...@rtems.org> wrote: > > > On Wed, Jul 4, 2018, 3:06 AM Chris Johns <chr...@rtems.org> wrote: > >> >> >> On 4/7/18 5:55 pm, Vijay Kumar Banerjee wrote: >> > On 4 July 2018 at 13:09, Chris Johns <chr...@rtems.org >> > <mailto:chr...@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@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel