On Sun, 10 Jun 2018, 20:52 Joel Sherrill, <j...@rtems.org> wrote: > > > On Sat, Jun 9, 2018, 6:02 PM Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> 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. >> > > We don't need it to gather its own information. Covoar generates it based > on the execution trace. If all this option does is instrument the generated > code and write results on exit, then we want to turn that off and teach > covoar to write the same files. > Yes that's all the option does. Understood. I'll try to figure out how the gcov code in covoar works/is supposed to work.
> > 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
