On Wed, Jul 4, 2018, 1:46 PM Vijay Kumar Banerjee <vijaykumar9...@gmail.com> wrote:
> 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> > 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@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel