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.
If you can figure out how to write a unit test that would be helpful.
On Thu, Jun 7, 2018 at 2:29 PM, Vijay Kumar Banerjee <
vijaykumar9...@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 <vijaykumar9...@gmail.com>
> wrote:
>
>>
>>
>> On Thu, 7 Jun 2018, 02:39 Joel Sherrill, <j...@rtems.org> wrote:
>>
>>>
>>>
>>> On Wed, Jun 6, 2018, 3:56 PM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> On 7 June 2018 at 01:48, Joel Sherrill <j...@rtems.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 6, 2018, 2:07 PM Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> On 6 June 2018 at 20:49, Joel Sherrill <j...@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/sc
>>>> ore/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 <
>>>>>>> vijaykumar9...@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@rtems.org
>>>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
