On Wed, 13 Jun 2018, 11:51 Joel Sherrill, <j...@rtems.org> wrote: > > > On Sun, Jun 10, 2018, 6:02 PM Vijay Kumar Banerjee < > vijaykumar9...@gmail.com> wrote: > >> >> >> 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. >> > > Just remember that we want no changes to the code running on the target. > So covoar has to generate any output like profiling, coverage days, etc. > from the qemu traces. I know that helps me keep it clear. > Understood.
> > As to the build error, make sure you have a fresh build with no > unnecessary changes to compile flags. > Okay, will try again. > > >>> 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