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? My reading of the gcc manual was that one of those options implicitly added an option to link with libgcov.a. please confirm that. > > > >> >> >>>>> >>>>> 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