On 10 June 2018 at 04:16, Joel Sherrill <j...@rtems.org> wrote: > I suggest this because it is a work around for you. The long term solution > could be to add the symbol to newlib's dummy RTEMS crt0.c, add it to > librtemscpu.a (which is the temporary hack I suggested), add a libgcov.a > implementation or stub to RTEMS, or modify GCC. > > Up until now, we have avoided gcc options which altered the code under > test. Test as you fly, fly as you test. This hints at a problem we need to > think through. Is the call actually needed? I don't know. > > (according to my understanding) To generate the gcov reports we would need it . the -ftest-coverage generates a gcno file that contains information about each branch in the code. a code compiled with -fprofile-arcs includes libgcov which gets invoked during the program exit. The coverage information is collected during runtime and dumped into gcda file by libgcov.
> On Sat, Jun 9, 2018, 5:38 PM Joel Sherrill <j...@rtems.org> wrote: > >> For now, add a file to libcsupport/src which provides the symbols needed. >> Make sure things are methods or data as needed. Check GCC source for the >> prototype. >> >> This looks like something that is going to need a lot of reading. > On Sat, Jun 9, 2018, 3:34 PM Vijay Kumar Banerjee < >> vijaykumar9...@gmail.com> wrote: >> >>> On 10 June 2018 at 01:28, Joel Sherrill <j...@rtems.org> wrote: >>> >>>> >>>> >>>> On Sat, Jun 9, 2018, 2:29 PM Vijay Kumar Banerjee < >>>> vijaykumar9...@gmail.com> wrote: >>>> >>>>> 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 >>>>> >>>>> ============================= >>>>> >>>> >>>> I completely understood that. When you look in config.log in what looks >>>> to be a leon3 subdirectory, what's in the log file? >>>> >>>> I have attached the config.log file . >>> >>> >>>> My reading of the gcc manual was that one of those options implicitly >>>> added an option to link with libgcov.a. please confirm that. >>>> >>> yes , -fprofile-arcs implicitly adds option to link with libgcov >>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>>>> >>>>>>>>> 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