error while building leon3 with gcov flags

Sat Jun 9 22:38:33 UTC 2018

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.

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