error while building leon3 with gcov flags

Sat Jun 9 19:25:01 UTC 2018

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?

>>>
>>> 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/103b15aa/attachment-0001.html>