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

[Vijay Kumar Banerjee]

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

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?
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.


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

>
>

>
> 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 .

>
>
>>> 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/20180511/9a03ba33/attachment-0002.html>