error while building leon3 with gcov flags

Sat Jun 9 19:58:45 UTC 2018

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?

My reading of the gcc manual was that one of those options implicitly added
an option to link with libgcov.a. please confirm that.

>
>
>
>>
>>
>>>>>
>>>>> 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/786a617d/attachment-0001.html>