error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On 10 June 2018 at 04:16, Joel Sherrill <joel at 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.

> On Sat, Jun 9, 2018, 5:38 PM Joel Sherrill <joel at 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 <
>> vijaykumar9597 at gmail.com> wrote:
>>
>>> On 10 June 2018 at 01:28, Joel Sherrill <joel at rtems.org> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Jun 9, 2018, 2:29 PM Vijay Kumar Banerjee <
>>>> vijaykumar9597 at gmail.com> wrote:
>>>>
>>>>> On 10 June 2018 at 00:55, Joel Sherrill <joel at rtems.org> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jun 9, 2018, 2:22 PM Vijay Kumar Banerjee <
>>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>>
>>>>>>> On 9 June 2018 at 19:56, Joel Sherrill <joel at rtems.org> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Jun 9, 2018, 6:01 AM Vijay Kumar Banerjee <
>>>>>>>> vijaykumar9597 at 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 <
>>>>>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, 8 Jun 2018, 01:09 Joel Sherrill, <joel at 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 <
>>>>>>>>>>> vijaykumar9597 at 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 <
>>>>>>>>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, 7 Jun 2018, 02:39 Joel Sherrill, <joel at rtems.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Wed, Jun 6, 2018, 3:56 PM Vijay Kumar Banerjee <
>>>>>>>>>>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 7 June 2018 at 01:48, Joel Sherrill <joel at rtems.org>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee <
>>>>>>>>>>>>>>>> vijaykumar9597 at gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 6 June 2018 at 20:49, Joel Sherrill <joel at 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 <
>>>>>>>>>>>>>>>>>> vijaykumar9597 at 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 at rtems.org
>>>>>>>>>>>>>>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20180610/8525dbdc/attachment-0002.html>