error while building leon3 with gcov flags

[Joel Sherrill]

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.

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