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. As to the build error, make sure you have a fresh build with no unnecessary changes to compile flags. >> 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
