error while building leon3 with gcov flags

[Vijay Kumar Banerjee]

On Wed, 13 Jun 2018, 11:51 Joel Sherrill, <joel at rtems.org> wrote:

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

>
> As to the build error, make sure you have a fresh build with no
> unnecessary changes to compile flags.
>
Okay, will try again.

>
>
>>> 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/20180613/53bf3ee6/attachment-0002.html>