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? >>> >>> 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
