V2 Add DWARF support to the rtemstoolkit and put it to use.

Thu May 10 19:39:20 UTC 2018

On Thu, May 10, 2018 at 2:15 PM, Vijay Kumar Banerjee <
vijaykumar9597 at gmail.com> wrote:

> Frankly, I'm totally confused at the moment. I'm not able to come up with
> a proper task list to serially go through.
>

We are to blame for that. You have been caught in the cross-fire of us all
testing Chris' updates and discussion of future improvements.

Ideally you can ignore this work until it is done. Testing it along the way
is
appreciated but don't let it distract you.

>
> according to my understanding (and proposal), the major goals are:
>
> 1. Get the coverage analysis running again and get it merged with the
> current master repo.
> 2. Generating line coverage reports using the gcov/lcov .
> 3. get covoar generate reports on a data-centric format (as Joel suggested
> in the proposal earlier, this needs a discussion on the choice of format.
> Chris probably has some thoughts about it.)
>
> looking at the above and the current status I need to break down it into
> subtasks. Here are some of the questions that'll help me understand
> properly.
>
> 1. before the current updates to covoar, the coverage analysis was
> generating the html and txt reports (which I posted) in the previous set
> up. Is that what we're targeting to achive with the current setup?
>

Yes.

And ultimately not be working on anyone's personal repo with unmerged
changes.

> 2. The covoar is under update as Chris is working on it, there are still
> some issues there, updating the main() module is, I guess, one of them.
> This needs to be done as the first step before the tester can generate
> reports.
>

Looks like it. It may have generated them before the fault. But I don't
know if the reports are trustworthy yet given the replacement of addr2line
with DWARF library. But when it works, yes.

More below.

>
>
> On 10 May 2018 at 23:40, Joel Sherrill <joel at rtems.org> wrote:
>
>> On Thu, May 10, 2018 at 12:37 PM, Cillian O'Donnell <
>> cpodonnell8 at gmail.com> wrote:
>>
>>> Ahhh I see, more c++ conversion for the rest of covoar, or at least the
>>> parts called in main. That's something Vijay could do, the blueprint for
>>> the conversion is in one of Chris last patches updating covoar.cc Any
>>> objections to him doing it Joel, Chris?
>>>
>>
>> None from me. This particular issue would be higher than many of the
>> other things Chris wants changed since it manifests as a bad exit().
>>
> I can surely try looking into it (any instructions ?). Also, Isn't Chris
> already on it ?
>
>>
>> But overall Vijay needs to get output from covar with covoar running
>> cleanly (no faults) so he can focus on gcov output and reporting
>> improvements.
>>
>> NOTE: I am still open to the idea that gcov, lcov, etc. may be able to
>> produce reports that we are completely happy with. They need to
>> at least be a working alternate. lcov output looks promising from
>> the samples I have seen:
>>
>> http://ltp.sourceforge.net/coverage/lcov/output/index.html
>>
>
> the report looks good
>

I think it looks good for web use.

We haven't defined solid requirements but one we know is that we have to
have
PDF (e.g. printable) and browseable reports.

I don't know about gcov/lcov -> PDF.

But first step is to get gcov output files, run gcov and lcov by hand, and
then
automate it.

Hopefully, it won't be hard to review the current output versus gcov/lcov
output
and spot discrepancies. As you do more complete runs, I recall all you had
to
do is start with 100% covered methods in the current format and see if
gcov/lcov matched.

So get output based on gcov files generated by covoar, use gcov/lcov
on them and produce nicely organized report sets, and hopefully along
the way, if there are differences in the coverage reported, we will spot
them.
Then fix those issues.

>
>>
>
>>
>> https://swarminglogic.com/jotting/2014_05_lcov has more complicated
>> reports
>> and instructions. It even includes a shell script to make Chris happy. LOL
>>
> thanks for the link, the inscructions are really helpful to get started.
>
>> Vijay.. my thought is that you need to get gcov files output from covoar.
>> Then automating running gcov or lcov (lcov looks nicer I think). That
>> should
>> be a nice place to be completely committed. Hopefully at this point, you
>> will be analyzing all of cpukit/ and we can find some discrepancies
>> between
>> covoar reports and lcov/gcov output. Then fix those.  That's just my
>> thoughts
>> though.
>>
> +So after the covoar runs with no issues and the coverage report shows
> some data, the next work       is to generate gcov output .
> + Then automating running lcov .
>

Yep. And fix discrepancies in the reports vs existing reports.

>
>>
>>>> I also need to figure out why the address has lost it's reference to
>>>> the source
>>>> table.
>>>>
>>>> Chris
>>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
>>
>> _______________________________________________
>> 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/20180510/8f2c23f1/attachment-0002.html>