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

[Vijay Kumar Banerjee]

On Fri, 11 May 2018, 01:09 Joel Sherrill, <joel at rtems.org> wrote:

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

>
>> 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.
>
Thanks for stating it in detail. I understood what we're looking for here .

>
> 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.
>
Yeah fixing any discrepancies.

>
>
>>
>>>
>>>>> 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/d803e7f6/attachment-0002.html>