error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On Sun, 10 Jun 2018, 20:52 Joel Sherrill, <joel at rtems.org> wrote:

>
>
> On Sat, Jun 9, 2018, 6:02 PM Vijay Kumar Banerjee <
> vijaykumar9597 at gmail.com> wrote:
>
>> 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.
>>
>
> 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.

>
> 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/7bfb2cd7/attachment-0002.html>