On Sat, Jun 9, 2018, 6:01 AM Vijay Kumar Banerjee <vijaykumar9...@gmail.com> wrote:
> Hello, > > I was going through the gcc manual for gcov > > https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html#Gcov-and-Optimization > > It mentions that the flag -fprofile-arcs is necessary for generating the > .gcda files. > I have tried it with a small hello world program to see the reports, and > it seems > that for .gcda files this flag is necessary. > > when I include the flag `-fprofile-arcs` with `-ftest-coverage` and then > make > I'm getting the following error. > > ============================= > checking whether the C compiler works... no > configure: error: in > `/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3': > configure: error: C compiler cannot create executables > See `config.log' for more details > gmake[2]: *** [Makefile:731: leon3] Error 1 > gmake[2]: Leaving directory > '/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c' > gmake[1]: *** [Makefile:289: all-recursive] Error 1 > gmake[1]: Leaving directory > '/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c' > gmake: *** [Makefile:414: all-recursive] Error 1 > > ============================= > It may be looking for a symbol provided by libgov.a. We don't have that based on how we do coverage. The normal approach is to add it to the RTEMS dummy crt0.c in newlib. > > > On 8 June 2018 at 01:13, Vijay Kumar Banerjee <vijaykumar9...@gmail.com> > wrote: > >> >> >> On Fri, 8 Jun 2018, 01:09 Joel Sherrill, <j...@rtems.org> wrote: >> >>> Bringing in Krzysztof. Hoping he can get us on the right track here. >>> >>> I don't think you can run GcovData.cc independent of a covoar run. >>> >> Understood. >> >>> If you can figure out how to write a unit test that would be helpful. >>> >> Will try to do that if possible. >> >>> >>> On Thu, Jun 7, 2018 at 2:29 PM, Vijay Kumar Banerjee < >>> vijaykumar9...@gmail.com> wrote: >>> >>>> Hello, >>>> >>>> I was looking into the code in GcovData.cc to see how it works >>>> and what it's doing, too me it looked like very messed up, I couldn't >>>> understand (yet) what it's trying to do. >>>> Is there some way I can manually run it for one file? >>>> Is there any place where I can read how it was intended to work? >>>> Or something like a flow diagram? >>>> >>>> >>>> -- vijay >>>> >>>> On 7 June 2018 at 02:56, Vijay Kumar Banerjee <vijaykumar9...@gmail.com >>>> > wrote: >>>> >>>>> >>>>> >>>>> On Thu, 7 Jun 2018, 02:39 Joel Sherrill, <j...@rtems.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, Jun 6, 2018, 3:56 PM Vijay Kumar Banerjee < >>>>>> vijaykumar9...@gmail.com> wrote: >>>>>> >>>>>>> On 7 June 2018 at 01:48, Joel Sherrill <j...@rtems.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee < >>>>>>>> vijaykumar9...@gmail.com> wrote: >>>>>>>> >>>>>>>>> On 6 June 2018 at 20:49, Joel Sherrill <j...@rtems.org> wrote: >>>>>>>>> >>>>>>>>>> I can't duplicate this. My configure command was: >>>>>>>>>> >>>>>>>>>> ../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=leon3 >>>>>>>>>> --prefix=/home/joel/rtems-work/tools/5 \ >>>>>>>>>> --disable-networking --enable-posix --disable-smp >>>>>>>>>> --disable-multiprocessing \ >>>>>>>>>> --enable-tests --enable-cxx --enable-maintainer-mode >>>>>>>>>> >>>>>>>>>> What was yours? >>>>>>>>>> >>>>>>>>>> I didn't have --enable-cxx and --enable-maintainer-more. >>>>>>>>> >>>>>>>>> I made some tries and somehow it's perfectly working now. >>>>>>>>> >>>>>>>>> I am trying to find out now how covoar generates the reports. >>>>>>>>> I made a file with a list of all gcno in score/ and run with -g >>>>>>>>> argument >>>>>>>>> now I'mg seeing the following error while running covoar >>>>>>>>> >>>>>>>>> ====================== >>>>>>>>> Generating Gcov reports... >>>>>>>>> Processing file: libscore_a-allocatormutex.gcno >>>>>>>>> Unable to open libscore_a-allocatormutex.gcno >>>>>>>>> Processing file: libscore_a-apimutexisowner.gcno >>>>>>>>> Unable to open libscore_a-apimutexisowner.gcno >>>>>>>>> Processing file: libscore_a-apimutexlock.gcno >>>>>>>>> Unable to open libscore_a-apimutexlock.gcno >>>>>>>>> Processing file: libscore_a-apimutexunlock.gcno >>>>>>>>> Unable to open libscore_a-apimutexunlock.gcno >>>>>>>>> Processing file: libscore_a-chain.gcno >>>>>>>>> Unable to open libscore_a-chain.gcno >>>>>>>>> Processing file: libscore_a-chainnodecount.gcno >>>>>>>>> . >>>>>>>>> . >>>>>>>>> . >>>>>>>>> ====================== >>>>>>>>> >>>>>>>> >>>>>>>> I suspect this is another instance of the path issues inside the >>>>>>>> build tree you and Cillian fixed earlier. >>>>>>>> >>>>>>>> correcting the path worked. >>>>>>> >>>>>> >>>>>> Submit a patch for this. It needs fixing to get 5onyour next issue. >>>>>> >>>>> It just needed the absolute path to be fed. >>>>> here's what I did. >>>>> I manually 'find' all the gcno files under score. >>>>> wrote it all in a file separated by newlines. >>>>> fed that file as an argument to covoar. >>>>> and that brought me here. >>>>> >>>>> So when we write script, these are the >>>>> things that will be done by the script. >>>>> >>>>> Once everything strats running manually, >>>>> we can proceed to write scripts. >>>>> >>>>>> >>>>>>> Now I'm getting this error. >>>>>>> >>>>>>> Generating Gcov reports... >>>>>>> Processing file: >>>>>>> sparc-rtems5/c/leon3/cpukit/score/src/libscore_a-kern_tc.gcno >>>>>>> ERROR: Unable to read string from gcov file >>>>>>> ERROR: Unable to read string length from gcov file >>>>>>> ERROR: Unable to read Function starting line number >>>>>>> Segmentation fault (core dumped) >>>>>>> >>>>>> >>>>>> Welcome to GSoC! You are now in new territory. :) >>>>>> >>>>> So here the real work begins! >>>>> >>>>>> >>>>>> Dig in and see what went wrong. Be aware.that GCC file formats may >>>>>> (or may not) be subject to.changing over time and this could just be >>>>>> bitrot. >>>>>> >>>>> I got started with it. >>>>> >>>>>> >>>>>> Gcov-dump is installed with the compiler. >>>>>> >>>>>> You should check it we have a .h file describing the file and it is >>>>>> out of date. >>>>>> >>>>> I'll look into it. >>>>> >>>>>> >>>>>> Also I think we now should bring the gsov maintainer in. >>>>>> >>>>> The covoar's gcov support needs to be reworked. >>>>> We can get the help of the expert here. >>>>> >>>>>> >>>>>> Good job! >>>>>> >>>>> Thanks. :) >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>>>> On Wed, Jun 6, 2018 at 9:40 AM, Vijay Kumar Banerjee < >>>>>>>>>> vijaykumar9...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> I have added the following changes in the >>>>>>>>>>> bsps/sparc/leon3/config/leon3.cfg >>>>>>>>>>> >>>>>>>>>>> ---------- >>>>>>>>>>> CFLAGS_OPTIMIZE_V = -Os -g >>>>>>>>>>> CFLAGS_OPTIMIZE_V += -ftest-coverage >>>>>>>>>>> ------- >>>>>>>>>>> >>>>>>>>>>> While trying to build with these flags, I got a bunch of >>>>>>>>>>> the following errors: >>>>>>>>>>> >>>>>>>>>>> ========== >>>>>>>>>>> {standard input}: Assembler messages: >>>>>>>>>>> {standard input}:6510: Error: can't resolve >>>>>>>>>>> `.data._SPARC_Counter' {.data._SPARC_Counter section} - `.LLtext0' >>>>>>>>>>> {.text >>>>>>>>>>> section} >>>>>>>>>>> {standard input}:6511: Error: can't resolve >>>>>>>>>>> `.data._SPARC_Counter' {.data._SPARC_Counter section} - `.LLtext0' >>>>>>>>>>> {.text >>>>>>>>>>> section} >>>>>>>>>>> >>>>>>>>>>> =================== >>>>>>>>>>> >>>>>>>>>>> after the `make install` I do get a lot of .gcno files, and no >>>>>>>>>>> executables. >>>>>>>>>>> >>>>>>>>>>> -- vijay >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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
