error while building leon3 with gcov flags

Sat Jun 9 19:22:07 UTC 2018

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 ? :)

>
>>
>> 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/70f8fae5/attachment-0001.html>