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

[Cillian O'Donnell]

On Thu, 10 May 2018, 22:23 Vijay Kumar Banerjee, <vijaykumar9597 at gmail.com>
wrote:

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

At the moment when the tester runs covoar the error messages generated are
a clear indicator of what is wrong, so task list is dictated by what
they're saying at the moment. Fixing the mismatch between exe.cov and .cov
is the next thing. The name is given as an argument to the -exec option of
the qemu cmd and is picked up from leon3-qemu-cov. Have a look at that and
see can you fix it.

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