On 10 June 2018 at 00:55, Joel Sherrill <j...@rtems.org> wrote: > > > On Sat, Jun 9, 2018, 2:22 PM Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> On 9 June 2018 at 19:56, Joel Sherrill <j...@rtems.org> wrote: >> >>> >>> >>> 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. >>> >> >> er.... looks confusing, are there any instructions ? :) >> > > What's the error first? What was in config.log in the directory with the > failure? > > I added this.
CFLAGS_OPTIMIZE_V += -fprofile-arcs -ftest-coverage when I `make` it, I see this 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 ============================= > > >>>> >>>> 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