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

[Vijay Kumar Banerjee]

On Fri, 11 May 2018, 02:19 Cillian O'Donnell, <cpodonnell8 at gmail.com> wrote:

>
>
> On 10 May 2018 at 20:15, 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.
>>
>> 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.
>>
>
> Yep, this is definitely the most immediate goal.
>
>
>> 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?
>>
>
> Exactly we need to see it doing what it was before and then this will be a
> good jumping off point for the other goals.
>
got it , It's Clear now.

>
>
>> 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.
>>
>
> What Chris is doing now, we can keep an eye on what's happening and help
> with testing but we won't need to wait for it to move forward. So getting
> the tester to run covoar is separate and we can crack on with that.
>
Understood.
have you set any 'plan' for how to approach this ?

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