error while building leon3 with gcov flags
Joel Sherrill
joel at rtems.org
Wed Jun 13 06:20:54 UTC 2018
On Sun, Jun 10, 2018, 6:02 PM Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
wrote:
>
>
> On Sun, 10 Jun 2018, 20:52 Joel Sherrill, <joel at rtems.org> wrote:
>
>>
>>
>> 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.
>>
> Yes that's all the option does.
> Understood. I'll try to figure out how the
> gcov code in covoar works/is supposed
> to work.
>
Just remember that we want no changes to the code running on the target. So
covoar has to generate any output like profiling, coverage days, etc. from
the qemu traces. I know that helps me keep it clear.
As to the build error, make sure you have a fresh build with no unnecessary
changes to compile flags.
>> 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/20180613/118095f5/attachment-0001.html>
More information about the devel
mailing list