Re: Improve coverage analysis toolset

[Cillian O'Donnell]

What's the full output and what did you change in the time in between
having the same output that I posted and the new one?

Start a new thread for this issue like Chris mentioned.

On Tue, 3 Apr 2018, 20:35 Vijay Kumar Banerjee, 
wrote:

>
>
>
>
> On 3 April 2018 at 03:58, Chris Johns  wrote:
>
>> On 03/04/2018 02:10, Cillian O'Donnell wrote:
>> > Sure if you want to crack at it.
>> >
>> > If you pull the ini-update branch again, I've included the other files
>> you'll need.
>> >
>> > Now if you try and run rtems-test with coverage you will get
>> >
>> > cpod@cpod ~ $
>> $HOME/development/rtems/test/rtems-tools/tester/rtems-test
>> > --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
>> > --rtems-bsp=leon3_qemu --coverage
>> --rtems-builddir=$HOME/development/rtems/leon3
>> > sparc-rtems5/c/leon3/testsuites/samples
>> > RTEMS Testing - Tester, 5 (80a1e6d9607e)
>> > Traceback (most recent call last):
>> >   File
>> "/home/cpod/development/rtems/test/rtems-tools/tester/rtems-test", line
>> > 40, in 
>> > rt.test.run()
>> >   File
>> "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py", line
>> > 310, in run
>> > coverage = coverage_get_obj(opts, path_to_builddir[1])
>> >   File
>> "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py", line
>> > 230, in coverage_get_obj
>> > coverage_obj = coverage.coverage_run(opts.defaults,
>> path_to_builddir)
>> >   File
>> "/home/cpod/development/rtems/test/rtems-tools/tester/rt/coverage.py",
>> > line 329, in __init__
>> > self.config_map = self.macros.macros['coverage']
>>
>
> I managed was getting these errors yesterday after pulling the changes but
> for some reason it's not working as expected , now .
> It's giving the error :
>  error: mandatory item not found in bsp section: bsp
> where can this error be coming from ?
>
>>
>> I would not access the 'macros' dictionary directly like this. It
>> circumvents
>> the map support. There is '__getitem__' support on the class which is
>> better but
>> still raises an exception on an index error. You can ask if a key is
>> present and
>> the 'get()' interface returns 'None' if not found.
>>
>> > KeyError: 'coverage'
>>
>> Can we please create new threads for new topics?
>>
>> Thanks
>> Chris
>>
>
> Thanks
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

On Wed, 4 Apr 2018, 11:18 Vijay Kumar Banerjee, 
wrote:

> I got the rtems-test running
>
> I found that get_item_names(section, err) in configuration.py  was
> returning an empty list to the
> item_names in load(bsp,opts) for config.py this was giving out the error
> mandatory item not found .
>
> I have attached the patch file .
>
> current status :
> rtems-test is running without coverage
>
> running coverage gives the following error :
>
> RTEMS Testing - Tester, 5 (092c569e81ae)
> Traceback (most recent call last):
>   File "/home/lunatic/development/rtems/rtems-tools/tester/rtems-test",
> line 40, in 
> rt.test.run()
>   File "/home/lunatic/development/rtems/rtems-tools/tester/rt/test.py",
> line 310, in run
> coverage = coverage_get_obj(opts, path_to_builddir[1])
>   File "/home/lunatic/development/rtems/rtems-tools/tester/rt/test.py",
> line 230, in coverage_get_obj
> coverage_obj = coverage.coverage_run(opts.defaults, path_to_builddir)
>   File
> "/home/lunatic/development/rtems/rtems-tools/tester/rt/coverage.py", line
> 335, in __init__
> self.report_format = self.config_map['report_format'][2]
>

This is back to the difference in cfg formats. It's looking for the last
line here

https://github.com/cillianodonnell/rtems-tools/blob/coverage/tester/rtems/testing/bsps/leon3-qemu.mc

Which is now

https://github.com/cillianodonnell/rtems-tools/blob/ini-update/tester/rtems/testing/bsps/leon3_qemu.ini

It's trying to grab the 'html' text so it can trigger the right section of
code in coverage.py

It's something just to tell which format we want the report to output

TypeError: 'NoneType' object has no attribute '__getitem__'
>
>
> Thanks
>
> -- vijay
>
> On 4 April 2018 at 11:16, Chris Johns  wrote:
>
>> On 04/04/2018 06:36, Vijay Kumar Banerjee wrote:
>> > after pulling the ini-update branch from
>> > https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>> >
>>
>> Any local changes?
>>
>> > I tried running the rtems-test with the following command
>> >
>> > $HOME/development/rtems/rtems-tools/tester/rtems-test
>> > --rtems-tools=$HOME/development/rtems/5 --log=coverage_analysis.log
>> > --rtems-bsp=leon3_qemu
>> --rtems-builddir=$HOME/development/rtems/kernel/leon3
>> > sparc-rtems5/c/leon3/testsuites/samples
>> >
>> > was getting the KeyError for 'coverage'
>> >
>>
>> Please paste the command and output as it appears in the terminal?
>>
>> > current status :
>> > the same command gives the error :
>> > "mandatory item not found in bsp section : bsp,"
>> > to make sure I didn't break something , I also tried running from a
>> freshly
>> > downloaded directory as well, it gives the same error.
>>
>> Did you try running the following command from the top of the source tree:
>>
>>  $ grep -r "mandatory item not found" *
>>
>> ?
>>
>> Chris
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

Ah that's good progress, those .cov files are supposed to be generated by
couverture-qemu as the test are run. They contain the trace data. Are you
definitely running couverture-qemu and not regular qemu?

On Thu, 12 Apr 2018, 17:41 Vijay Kumar Banerjee, 
wrote:

> I got the parsing of the coverage from the ini file running , now I'm
> getting the following error and warnings .
>
>
> 
>
> Running covoar for score
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture/capture.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/cdtest/cdtest.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/fileio/fileio.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/iostream/cxx_iostream.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/loopback/loopback.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/minimum/minimum.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/nsecs/nsecs.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/paranoia/paranoia.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/pppd/pppd.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/ticker/ticker.exe.cov
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe.cov
> ERROR: No information to analyze
> ***Cleaning tempfiles***
> error: covoar failure exit code: 1
>
>
>
>
> -- vijay
>
> On 10 April 2018 at 18:10, Vijay Kumar Banerjee 
> wrote:
>
>> I managed to get the tests running with the following two patches .
>> Please review them .
>>
>> -- vijay
>>
>> On 9 April 2018 at 15:28, Vijay Kumar Banerjee 
>> wrote:
>>
>>>
>>>
>>> On Fri, 6 Apr 2018, 02:24 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> I tried to solve the empty get in the way shown in the patch , but it
>>>> doesn't seems to work, I'm getting the following error now
>>>>
>>>> RTEMS Testing - Tester, 5 (1ed6e2e64090)
>>>> Traceback (most recent call last):
>>>>   File "/home/lunatic/development/rtems/rtems-tools/tester/rtems-test",
>>>> line 40, in 
>>>> rt.test.run()
>>>>   File "/home/lunatic/development/rtems/rtems-tools/tester/rt/test.py",
>>>> line 303, in run
>>>> bsp = config.load(bsp[1], opts)
>>>>   File
>>>> "/home/lunatic/development/rtems/rtems-tools/tester/rt/config.py", line
>>>> 461, in load
>>>> return opts.defaults['bsp']
>>>>   File
>>>> "/home/lunatic/development/rtems/rtems-tools/rtemstoolkit/macros.py", line
>>>> 190, in __getitem__
>>>> raise IndexError('key: %s' % (key))
>>>> IndexError: key: bsp
>>>>
>>>> I still Couldn't figure out why it's happening, when I use
>>> RawConfigParse , it seems to run nicely though .
>>>
>>> Any Ideas on solving it without using RawConfigParser ?
>>>
>>>
>>>> -- vijay
>>>>
>>>> On 5 April 2018 at 11:51, Cillian O'Donnell 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, 4 Apr 2018, 11:18 Vijay Kumar Banerjee, <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> I got the rtems-test running
>>>>>>
>>>>>> I found that get_item_names(section, err) in configurati

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

No that's the right one. I think it might be something to do with qemu.cfg
in rtems-tools then. What's in your qemu.cfg? It's in
rtems-tools/tester/rtems/testing

On Fri, 13 Apr 2018, 06:39 Vijay Kumar Banerjee, 
wrote:

> I manually built qemu from here
>
> https://github.com/AdaCore/qemu
>
> I guess this is regular qemu , please send a link for couverture qemu for
> manual build.
>
> -- vijay
>
> On 12 April 2018 at 22:23, Cillian O'Donnell 
> wrote:
>
>> Ah that's good progress, those .cov files are supposed to be generated by
>> couverture-qemu as the test are run. They contain the trace data. Are you
>> definitely running couverture-qemu and not regular qemu?
>>
>> On Thu, 12 Apr 2018, 17:41 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> I got the parsing of the coverage from the ini file running , now I'm
>>> getting the following error and warnings .
>>>
>>>
>>> 
>>>
>>> Running covoar for score
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture/capture.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/cdtest/cdtest.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/fileio/fileio.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/iostream/cxx_iostream.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/loopback/loopback.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/minimum/minimum.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/nsecs/nsecs.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/paranoia/paranoia.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/pppd/pppd.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/ticker/ticker.exe.cov
>>> WARNING: Unable to read coverage file
>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe.cov
>>> ERROR: No information to analyze
>>> ***Cleaning tempfiles***
>>> error: covoar failure exit code: 1
>>>
>>>
>>>
>>>
>>> -- vijay
>>>
>>> On 10 April 2018 at 18:10, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> I managed to get the tests running with the following two patches .
>>>> Please review them .
>>>>
>>>> -- vijay
>>>>
>>>> On 9 April 2018 at 15:28, Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, 6 Apr 2018, 02:24 Vijay Kumar Banerjee, <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> I tried to solve the empty get in the way shown in the patch , but it
>>>>>> doesn't seems to work, I'm getting the following error now
>>>>>>
>>>>>> RTEMS Testing - Tester, 5 (1ed6e2e64090)
>>>>>> Traceback (most recent call last):
>>>>>>   File
>>>>>> "/home/lunatic/development/rtems/rtems-tools/tester/rtems-test", line 40,
>>>>>> in 
>>>>>> rt.test.run()
>>>>>>   File
>>>>>> "/home/lunatic/development/rtems/rtems-tools/tester/rt/test.py", line 
>>>>>> 303,
>>>>>> in run
>>>>&g

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

Yeah that's fine but can you just paste the contents here anyway. I'm not
near a laptop and I can't remember which branch your starting from.

On Fri, 13 Apr 2018, 13:51 Vijay Kumar Banerjee, 
wrote:

> I haven't made any local changes to qemu.cfg
>
> -- vijay
>
> On 13 April 2018 at 11:43, Cillian O'Donnell 
> wrote:
>
>> No that's the right one. I think it might be something to do with
>> qemu.cfg in rtems-tools then. What's in your qemu.cfg? It's in
>> rtems-tools/tester/rtems/testing
>>
>> On Fri, 13 Apr 2018, 06:39 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> I manually built qemu from here
>>>
>>> https://github.com/AdaCore/qemu
>>>
>>> I guess this is regular qemu , please send a link for couverture
>>> qemu for manual build.
>>>
>>> -- vijay
>>>
>>> On 12 April 2018 at 22:23, Cillian O'Donnell 
>>> wrote:
>>>
>>>> Ah that's good progress, those .cov files are supposed to be generated
>>>> by couverture-qemu as the test are run. They contain the trace data. Are
>>>> you definitely running couverture-qemu and not regular qemu?
>>>>
>>>> On Thu, 12 Apr 2018, 17:41 Vijay Kumar Banerjee, <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> I got the parsing of the coverage from the ini file running , now I'm
>>>>> getting the following error and warnings .
>>>>>
>>>>>
>>>>> 
>>>>>
>>>>> Running covoar for score
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture/capture.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/cdtest/cdtest.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/fileio/fileio.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/iostream/cxx_iostream.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/loopback/loopback.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/minimum/minimum.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/nsecs/nsecs.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/paranoia/paranoia.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/pppd/pppd.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/ticker/ticker.exe.cov
>>>>> WARNING: Unable to read coverage file
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe.cov
>>>>> ERROR: No information to analyze
>>>>> ***Cleaning tempfiles***
>>>>> error: covoar failure exit code: 1
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- vijay
>>>>>
>>>>> On 10 April 2018 at 18:10, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> I managed to get the tests running with the following two patches .
>>>>>> Please review them .
>>>>>>
>>>>>> -- vijay
>>>>>>
>>>>>> On 9 April 2018 at 15:28, Vijay Kumar Banerjee <
>

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

Ah yes, your missing the qemu arguments to run the coverage. Try this

#
# Coverage analysis
#
%define coverage_arg %{nil}
%if %{defined _coverage}
%if %{coverage_supported}
%define coverage_arg -exec-trace %{test_executable}.cov
%else
%error "Coverage analysis unsupported for %{bsp}"
%endif
%endif

#
# Executable
#
%execute %{qemu_cmd} %{qemu_opts_base} %{qemu_opts} -kernel
%{test_executable} %{coverage_arg}


On Fri, 13 Apr 2018, 18:18 Vijay Kumar Banerjee, 
wrote:

> sure
>
> .
>
> #
> # RTEMS Tools Project (http://www.rtems.org/)
> # Copyright 2010-2014 Chris Johns (chr...@rtems.org)
> # All rights reserved.
> #
> # This file is part of the RTEMS Tools package in 'rtems-tools'.
> #
> # Redistribution and use in source and binary forms, with or without
> # modification, are permitted provided that the following conditions are
> met:
> #
> # 1. Redistributions of source code must retain the above copyright notice,
> # this list of conditions and the following disclaimer.
> #
> # 2. Redistributions in binary form must reproduce the above copyright
> notice,
> # this list of conditions and the following disclaimer in the documentation
> # and/or other materials provided with the distribution.
> #
> # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> # AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> # ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
> # LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> # SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> # INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> # CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> # ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> # POSSIBILITY OF SUCH DAMAGE.
> #
>
> #
> # QEMU
> #
> # Use a qemu command to run the executable in the qemu simulator.
> #
>
> %include %{_configdir}/base.cfg
> %include %{_configdir}/checks.cfg
>
> #
> # Console.
> #
> %define console_stdio
> %include %{_configdir}/console.cfg
>
> #
> # RTEMS version
> #
> %include %{_rtdir}/rtems/version.cfg
>
> #
> # Qemu common option patterns.
> #
> #%define qemu_opts_base   -no-reboot -monitor none -serial stdio -nographic
> #%define qemu_opts_base   -no-reboot -serial null -serial mon:stdio
> -nographic
> %define qemu_opts_base  -no-reboot -monitor null -serial stdio -nographic
> %define qemu_opts_no_net -net none
> #
> # Qemu executable
> #
> %ifn %{defined bsp_qemu_opts}
>  %define bsp_qemu_opts %{nil}
> %endif
> %define qemu_cmd  qemu-system-%{bsp_arch}
> %define qemu_opts %{bsp_qemu_opts}
>
> #
> # Executable
> #
> %execute %{qemu_cmd} %{qemu_opts} -kernel %{test_executable}
>
> -- vijay
>
> On 13 April 2018 at 22:19, Cillian O'Donnell 
> wrote:
>
>> Yeah that's fine but can you just paste the contents here anyway. I'm not
>> near a laptop and I can't remember which branch your starting from.
>>
>> On Fri, 13 Apr 2018, 13:51 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> I haven't made any local changes to qemu.cfg
>>>
>>> -- vijay
>>>
>>> On 13 April 2018 at 11:43, Cillian O'Donnell 
>>> wrote:
>>>
>>>> No that's the right one. I think it might be something to do with
>>>> qemu.cfg in rtems-tools then. What's in your qemu.cfg? It's in
>>>> rtems-tools/tester/rtems/testing
>>>>
>>>> On Fri, 13 Apr 2018, 06:39 Vijay Kumar Banerjee, <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> I manually built qemu from here
>>>>>
>>>>> https://github.com/AdaCore/qemu
>>>>>
>>>>> I guess this is regular qemu , please send a link for couverture
>>>>> qemu for manual build.
>>>>>
>>>>> -- vijay
>>>>>
>>>>> On 12 April 2018 at 22:23, Cillian O'Donnell 
>>>>> wrote:
>>>>>
>>>>>> Ah that's good progress, those .cov files are supposed to be
>>>>>> generated by couverture-qemu as the test are run. They contain the trace
>>>>>> data. Are you definitely running couverture-qemu and not regular qemu?
>>&g

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

Alright so we're back to ini update stuff. That error is because in the old
leon3-qemu.mc we had this global variable set. So you need to find out how
to get that global variable set in the new leon3-qemu.ini

Heres the old version from the .MC file

[global]
bsp:  none,none, 'leon3'
coverage_supported:   none,none, '1'


On Fri, 13 Apr 2018, 18:29 Vijay Kumar Banerjee, 
wrote:

> It shows the following error
>
> ...
> RTEMS Testing - Tester, 5 (58acb6d61ac7 modified)
> Coverage environment prepared
> [ 3/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3_qemu:
> cdtest.exe
> [ 1/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3_qemu:
> base_sp.exe
> [ 2/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3_qemu:
> capture.exe
> [ 4/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3_qemu:
> fileio.exe
> error: qemu.cfg:77: macro '%{coverage_supported}' not found
> warning: switched to dry run due to errors
> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
> error: qemu.cfg:77: macro '%{coverage_supported}' not found
> warning: switched to dry run due to errors
> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
> Traceback (most recent call last):
>   File
> "/home/lunatic/development/rtems/test/rtems-tools/tester/rtems-test", line
> 40, in 
> rt.test.run()
>   File
> "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py", line
> 353, in run
> tst.reraise()
>   File
> "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py", line
> 160, in reraise
> _test_reraise(*self.result)
> NameError: global name '_test_reraise' is not defined
> error: qemu.cfg:77: macro '%{coverage_supported}' not found
> warning: switched to dry run due to errors
> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
> error: qemu.cfg:77: macro '%{coverage_supported}' not found
> warning: switched to dry run due to errors
> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
>
>
>
> -- vijay
>
> On 13 April 2018 at 22:54, Cillian O'Donnell 
> wrote:
>
>> Ah yes, your missing the qemu arguments to run the coverage. Try this
>>
>> #
>> # Coverage analysis
>> #
>> %define coverage_arg %{nil}
>> %if %{defined _coverage}
>> %if %{coverage_supported}
>> %define coverage_arg -exec-trace %{test_executable}.cov
>> %else
>> %error "Coverage analysis unsupported for %{bsp}"
>> %endif
>> %endif
>>
>> #
>> # Executable
>> #
>> %execute %{qemu_cmd} %{qemu_opts_base} %{qemu_opts} -kernel 
>> %{test_executable} %{coverage_arg}
>>
>>
>> On Fri, 13 Apr 2018, 18:18 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> sure
>>>
>>> .
>>>
>>> #
>>> # RTEMS Tools Project (http://www.rtems.org/)
>>> # Copyright 2010-2014 Chris Johns (chr...@rtems.org)
>>> # All rights reserved.
>>> #
>>> # This file is part of the RTEMS Tools package in 'rtems-tools'.
>>> #
>>> # Redistribution and use in source and binary forms, with or without
>>> # modification, are permitted provided that the following conditions are
>>> met:
>>> #
>>> # 1. Redistributions of source code must retain the above copyright
>>> notice,
>>> # this list of conditions and the following disclaimer.
>>> #
>>> # 2. Redistributions in binary form must reproduce the above copyright
>>> notice,
>>> # this list of conditions and the following disclaimer in the
>>> documentation
>>> # and/or other materials provided with the distribution.
>>> #
>>> # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>> "AS IS"
>>> # AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
>>> THE
>>> # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>>> PURPOSE
>>> # ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
>>> BE
>>> # LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>>> # CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>>> # SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>>> BUSINESS
>>> # INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>&

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

I can't say for certain but I don't think that will be visible to qemu.cfg
unless it's a global variable. Chris might know off the top of his head.

On Fri, 13 Apr 2018, 18:51 Vijay Kumar Banerjee, 
wrote:

> can we set it in [coverage] ?
>
> -- vijay
>
> On 13 April 2018 at 23:15, Cillian O'Donnell 
> wrote:
>
>> Alright so we're back to ini update stuff. That error is because in the
>> old leon3-qemu.mc we had this global variable set. So you need to find
>> out how to get that global variable set in the new leon3-qemu.ini
>>
>> Heres the old version from the .MC file
>>
>> [global]
>> bsp:  none,none, 'leon3'
>> coverage_supported:   none,none, '1'
>>
>>
>> On Fri, 13 Apr 2018, 18:29 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> It shows the following error
>>>
>>> ...
>>> RTEMS Testing - Tester, 5 (58acb6d61ac7 modified)
>>> Coverage environment prepared
>>> [ 3/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3_qemu:
>>> cdtest.exe
>>> [ 1/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3_qemu:
>>> base_sp.exe
>>> [ 2/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3_qemu:
>>> capture.exe
>>> [ 4/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  | sparc/leon3_qemu:
>>> fileio.exe
>>> error: qemu.cfg:77: macro '%{coverage_supported}' not found
>>> warning: switched to dry run due to errors
>>> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
>>> error: qemu.cfg:77: macro '%{coverage_supported}' not found
>>> warning: switched to dry run due to errors
>>> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
>>> Traceback (most recent call last):
>>>   File
>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rtems-test", line
>>> 40, in 
>>> rt.test.run()
>>>   File
>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py", line
>>> 353, in run
>>> tst.reraise()
>>>   File
>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py", line
>>> 160, in reraise
>>> _test_reraise(*self.result)
>>> NameError: global name '_test_reraise' is not defined
>>> error: qemu.cfg:77: macro '%{coverage_supported}' not found
>>> warning: switched to dry run due to errors
>>> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
>>> error: qemu.cfg:77: macro '%{coverage_supported}' not found
>>> warning: switched to dry run due to errors
>>> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
>>>
>>>
>>>
>>> -- vijay
>>>
>>> On 13 April 2018 at 22:54, Cillian O'Donnell 
>>> wrote:
>>>
>>>> Ah yes, your missing the qemu arguments to run the coverage. Try this
>>>>
>>>> #
>>>> # Coverage analysis
>>>> #
>>>> %define coverage_arg %{nil}
>>>> %if %{defined _coverage}
>>>> %if %{coverage_supported}
>>>> %define coverage_arg -exec-trace %{test_executable}.cov
>>>> %else
>>>> %error "Coverage analysis unsupported for %{bsp}"
>>>> %endif
>>>> %endif
>>>>
>>>> #
>>>> # Executable
>>>> #
>>>> %execute %{qemu_cmd} %{qemu_opts_base} %{qemu_opts} -kernel 
>>>> %{test_executable} %{coverage_arg}
>>>>
>>>>
>>>> On Fri, 13 Apr 2018, 18:18 Vijay Kumar Banerjee, <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> sure
>>>>>
>>>>> .
>>>>>
>>>>> #
>>>>> # RTEMS Tools Project (http://www.rtems.org/)
>>>>> # Copyright 2010-2014 Chris Johns (chr...@rtems.org)
>>>>> # All rights reserved.
>>>>> #
>>>>> # This file is part of the RTEMS Tools package in 'rtems-tools'.
>>>>> #
>>>>> # Redistribution and use in source and binary forms, with or without
>>>>> # modification, are permitted provided that the following conditions
>>>>> are met:
>>>>> #
>>>>> # 1. Redistributions of source code mus

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

Is there anywhere in that output that it shows the qemu command that is
running?

On Fri, 13 Apr 2018, 19:02 Vijay Kumar Banerjee, 
wrote:

>
> -- vijay
>
> On 13 April 2018 at 23:29, Cillian O'Donnell 
> wrote:
>
>> I can't say for certain but I don't think that will be visible to
>> qemu.cfg unless it's a global variable. Chris might know off the top of his
>> head.
>>
>> On Fri, 13 Apr 2018, 18:51 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> can we set it in [coverage] ?
>>>
>>> It runs with the same warnings of unable to read the .cov files
>
>
>> -- vijay
>>>
>>> On 13 April 2018 at 23:15, Cillian O'Donnell 
>>> wrote:
>>>
>>>> Alright so we're back to ini update stuff. That error is because in the
>>>> old leon3-qemu.mc we had this global variable set. So you need to find
>>>> out how to get that global variable set in the new leon3-qemu.ini
>>>>
>>>> Heres the old version from the .MC file
>>>>
>>>> [global]
>>>> bsp:  none,none, 'leon3'
>>>> coverage_supported:   none,none, '1'
>>>>
>>>>
>>>> On Fri, 13 Apr 2018, 18:29 Vijay Kumar Banerjee, <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> It shows the following error
>>>>>
>>>>> ...
>>>>> RTEMS Testing - Tester, 5 (58acb6d61ac7 modified)
>>>>> Coverage environment prepared
>>>>> [ 3/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>>>> sparc/leon3_qemu: cdtest.exe
>>>>> [ 1/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>>>> sparc/leon3_qemu: base_sp.exe
>>>>> [ 2/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>>>> sparc/leon3_qemu: capture.exe
>>>>> [ 4/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  W:0  |
>>>>> sparc/leon3_qemu: fileio.exe
>>>>> error: qemu.cfg:77: macro '%{coverage_supported}' not found
>>>>> warning: switched to dry run due to errors
>>>>> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
>>>>> error: qemu.cfg:77: macro '%{coverage_supported}' not found
>>>>> warning: switched to dry run due to errors
>>>>> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
>>>>> Traceback (most recent call last):
>>>>>   File
>>>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rtems-test", line
>>>>> 40, in 
>>>>> rt.test.run()
>>>>>   File
>>>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py", line
>>>>> 353, in run
>>>>> tst.reraise()
>>>>>   File
>>>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py", line
>>>>> 160, in reraise
>>>>> _test_reraise(*self.result)
>>>>> NameError: global name '_test_reraise' is not defined
>>>>> error: qemu.cfg:77: macro '%{coverage_supported}' not found
>>>>> warning: switched to dry run due to errors
>>>>> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
>>>>> error: qemu.cfg:77: macro '%{coverage_supported}' not found
>>>>> warning: switched to dry run due to errors
>>>>> error: qemu.cfg:77: invalid if bool value:  %if %{coverage_supported}
>>>>>
>>>>>
>>>>>
>>>>> -- vijay
>>>>>
>>>>> On 13 April 2018 at 22:54, Cillian O'Donnell 
>>>>> wrote:
>>>>>
>>>>>> Ah yes, your missing the qemu arguments to run the coverage. Try this
>>>>>>
>>>>>> #
>>>>>> # Coverage analysis
>>>>>> #
>>>>>> %define coverage_arg %{nil}
>>>>>> %if %{defined _coverage}
>>>>>> %if %{coverage_supported}
>>>>>> %define coverage_arg -exec-trace %{test_executable}.cov
>>>>>> %else
>>>>>> %error "Coverage analysis unsupported for %{bsp}"
>>>>>> %endif
>>>>>> %endif
>>>>>>
>>>>>> #
>>>>>

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

Hmmm it's not there. Even so I can almost guarantee you, the reason it's
not running is that coverage_supported variable is not being found as true
in qemu.cfg and so the the command to generated the trace files isn't run
and there's no .cov files in the end. So that's what you'll have to dig
into.

On Fri, 13 Apr 2018, 19:16 Vijay Kumar Banerjee, 
wrote:

> It just shows this.(with only hello)
>
> Running covoar for score
> WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe.cov
> ERROR: No information to analyze
> ***Cleaning tempfiles***
> error: covoar failure exit code: 1
>
> 
> The log file shows this
> ..
> RTEMS Testing - Tester, 5 (58acb6d61ac7 modified)
>   2  Command Line:
> /home/lunatic/development/rtems/test/rtems-tools/tester/rtems-test
> --rtems-tools=/home/lunatic/development/rtems/5
> --log=coverage_analysis.log --rtems-bsp=leon3_qemu --coverage
> --rtems-builddir=/home/lunatic/development/rtems/kernel/leon3
> sparc-rtems5/c/leon3/testsuites/samples/hello
>   3  Python: 2.7.14 (default, Feb 27 2018, 20:43:24) [GCC 7.3.1 20180130
> (Red Hat 7.3.1-2)]
>   4 Host: Linux-4.15.8-300.fc27.x86_64-x86_64-with-fedora-27-Twenty_Seven
> (Linux lunatic 4.15.8-300.fc27.x86_64 #1 SMP Fri Mar 9 18:11:36 UTC
> 2018 x86_64 x86_64)
>   5 Coverage environment prepared
>   6 [1/1] p:0 f:0 u:0 e:0 I:0 B:0 t:0 i:0 W:0 | sparc/leon3_qemu: hello.exe
>   7
>   8 Passed:1
>   9 Failed:0
>  10 User Input:0
>  11 Expected Fail: 0
>  12 Indeterminate: 0
>  13 Benchmark: 0
>  14 Timeout:   0
>  15 Invalid:   0
>  16 Wrong Version: 0
>  17 Wrong Build:   0
>  18 Wrong Tools:   0
>  19 
>  20 Total: 1
>  21
>  22 Average test time: 0:00:01.505199
>  23 Testing time : 0:00:01.505199
>  24 Running covoar for score
>  25 shell: covoar -s /home/lunatic/coverage_test/coverage/score.symcfg -O
> /home/lunatic/coverage_test/test/score -f QEMU -T sparc-rtems5 -E
> /home/lunatic/development/rtems/test/rtems-too
> ls/tester/rtems/testing/coverage/Explanations.txt -c .cov -e exe -p RTEMS-5
> /home/lunatic/d
> evelopment/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>  26 WARNING: Unable to read coverage file
> /home/lunatic/development/rtems/kernel/leon3/sparc-rt
> ems5/c/leon3/testsuites/samples/hello/hello.exe.cov
>
>1,1   Top
>
>
> -- vijay
>
> On 13 April 2018 at 23:40, Cillian O'Donnell 
> wrote:
>
>> Is there anywhere in that output that it shows the qemu command that is
>> running?
>>
>> On Fri, 13 Apr 2018, 19:02 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>> -- vijay
>>>
>>> On 13 April 2018 at 23:29, Cillian O'Donnell 
>>> wrote:
>>>
>>>> I can't say for certain but I don't think that will be visible to
>>>> qemu.cfg unless it's a global variable. Chris might know off the top of his
>>>> head.
>>>>
>>>> On Fri, 13 Apr 2018, 18:51 Vijay Kumar Banerjee, <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> can we set it in [coverage] ?
>>>>>
>>>>> It runs with the same warnings of unable to read the .cov files
>>>
>>>
>>>> -- vijay
>>>>>
>>>>> On 13 April 2018 at 23:15, Cillian O'Donnell 
>>>>> wrote:
>>>>>
>>>>>> Alright so we're back to ini update stuff. That error is because in
>>>>>> the old leon3-qemu.mc we had this global variable set. So you need
>>>>>> to find out how to get that global variable set in the new leon3-qemu.ini
>>>>>>
>>>>>> Heres the old version from the .MC file
>>>>>>
>>>>>> [global]
>>>>>> bsp:  none,none, 'leon3'
>>>>>> coverage_supported:   none,none, '1'
>>>>>>
>>>>>>
>>>>>> On Fri, 13 Apr 2018, 18:29 Vijay Kumar Banerjee, <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> It shows the following error
>>>>>>>
>>>>>>> ...
>>>>>>> RTEMS Testing - Tester, 5 (58acb6d61ac7 modified)
>>>>>>> Coverage environment prepared
>&

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

On 14 April 2018 at 07:11, Chris Johns  wrote:

> On 14/4/18 8:02 am, Vijay Kumar Banerjee wrote:
>
>> Getting this error now seems like something is missing.
>>
>> 
>>
>> RTEMS Testing - Tester, 5 (b2ba08b0da42 modified)
>> Coverage environment prepared
>> Traceback (most recent call last):
>>File "/home/lunatic/development/rtems/test/rtems-tools/tester/rtems-test",
>> line 40, in 
>>  rt.test.run()
>>File "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py",
>> line 353, in run
>>  tst.reraise()
>>File "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py",
>> line 160, in reraise
>>  _test_reraise(*self.result)
>> NameError: global name '_test_reraise' is not defined
>>
>>
> The reraise logic was moved to the rtemstoolkit last year:
>
> https://git.rtems.org/rtems-tools/commit/?id=fa81491764861e6
> 3785a3faa241c488469087209
>
> It had some issues that have been fixed and it is being reused else where
> in the tester.
>
>
>> -- vijay
>>
>> On 13 April 2018 at 23:57, Vijay Kumar Banerjee > <mailto:vijaykumar9...@gmail.com>> wrote:
>>
>>
>>
>> On 13 April 2018 at 23:51, Cillian O'Donnell > <mailto:cpodonne...@gmail.com>> wrote:
>>
>> Hmmm it's not there. Even so I can almost guarantee you, the
>> reason it's not running is that coverage_supported variable is
>> not being found as true in qemu.cfg and so the the command to
>> generated the trace files isn't run and there's no .cov files in
>> the end. So that's what you'll have to dig into.
>>
>> Okay , I'll set it to global then.
>>
>>
> Changes need to be on the latest version of master before I will review
> them. The failure above indicate the code you have is not up to date.
>

Yes that was the plan. Just to check Vijay your starting point was using
the ini-update branch from here?

https://github.com/cillianodonnell/rtems-tools/tree/ini-update

That branch is current rtems-tools master that I started to add things back
in. The only reraise in there is the one improrted from rtemstoolkit.

>
> The change you have made is generating an exception in the tester thread.
> If you want to continue down this path you will need to fix what ever you
> have added.
>
> The tests are run as threads separate from the main thread so the
> exception is caught and re-raised in the main thread letting you know. This
> is broken in the old code base you are using.
>
> Why not investigate the reason as indicated and sort if out what the new
> format configuration file needs?
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

Switch one of these lines out in qemu.cfg.

#%define qemu_opts_base -no-reboot -monitor none -serial stdio -nographic
#%define qemu_opts_base -no-reboot -serial null -serial mon:stdio -nographic
%define qemu_opts_base -no-reboot -monitor null -serial stdio -nographic

Just comment out the one that's being used and uncomment one of the others.
It should cause a complaint when the tests are run and the qemu cmd should
show up in the log so we can take a look at it.

On 14 April 2018 at 20:37, Vijay Kumar Banerjee 
wrote:

>
>
> -- vijay
>
> On 15 April 2018 at 00:50, Vijay Kumar Banerjee 
> wrote:
>
>>
>>
>>
>> On 14 April 2018 at 16:42, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 14 April 2018 at 07:11, Chris Johns  wrote:
>>>
>>>> On 14/4/18 8:02 am, Vijay Kumar Banerjee wrote:
>>>>
>>>>> Getting this error now seems like something is missing.
>>>>>
>>>>> 
>>>>>
>>>>> RTEMS Testing - Tester, 5 (b2ba08b0da42 modified)
>>>>> Coverage environment prepared
>>>>> Traceback (most recent call last):
>>>>>File 
>>>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rtems-test",
>>>>> line 40, in 
>>>>>  rt.test.run()
>>>>>File 
>>>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py",
>>>>> line 353, in run
>>>>>  tst.reraise()
>>>>>File 
>>>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py",
>>>>> line 160, in reraise
>>>>>  _test_reraise(*self.result)
>>>>> NameError: global name '_test_reraise' is not defined
>>>>>
>>>>>
>>>> The reraise logic was moved to the rtemstoolkit last year:
>>>>
>>>> https://git.rtems.org/rtems-tools/commit/?id=fa81491764861e6
>>>> 3785a3faa241c488469087209
>>>>
>>>> It had some issues that have been fixed and it is being reused else
>>>> where in the tester.
>>>>
>>>>
>>>>> -- vijay
>>>>>
>>>>> On 13 April 2018 at 23:57, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com <mailto:vijaykumar9...@gmail.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 13 April 2018 at 23:51, Cillian O'Donnell <
>>>>> cpodonne...@gmail.com
>>>>> <mailto:cpodonne...@gmail.com>> wrote:
>>>>>
>>>>> Hmmm it's not there. Even so I can almost guarantee you, the
>>>>> reason it's not running is that coverage_supported variable is
>>>>> not being found as true in qemu.cfg and so the the command to
>>>>> generated the trace files isn't run and there's no .cov files
>>>>> in
>>>>> the end. So that's what you'll have to dig into.
>>>>>
>>>>> Okay , I'll set it to global then.
>>>>>
>>>>>
>>>> Changes need to be on the latest version of master before I will review
>>>> them. The failure above indicate the code you have is not up to date.
>>>>
>>>
>>> Yes that was the plan. Just to check Vijay your starting point was using
>>> the ini-update branch from here?
>>>
>>> https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>>>
>>> That branch is current rtems-tools master that I started to add things
>>> back in. The only reraise in there is the one improrted from rtemstoolkit.
>>>
>>
>> yes this is the branch I'm using , I checked the reraise error , not
>> sure how it showed up buit I called it from the reraise module , and it
>> got fixed . now I'm stuck here
>>
>> error: config error: qemu.cfg:36: No 'target' defined
>>
>
> okay , fixed that .
> still getting the warnings of the unable to read .cov
>
>>
>> are we supposed to set the bsp to global as well ?
>>
>>
>>>> The change you have made is generating an exception in the tester
>>>> thread. If you want to continue down this path you will need to fix what
>>>> ever you have added.
>>>>
>>>> The tests are run as threads separate from the main thread so the
>>>> exception is caught and re-raised in the main thread letting you know. This
>>>> is broken in the old code base you are using.
>>>>
>>>> Why not investigate the reason as indicated and sort if out what the
>>>> new format configuration file needs?
>>>>
>>>> Chris
>>>>
>>>
>>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

On 15 April 2018 at 06:46, Vijay Kumar Banerjee 
wrote:

>
>
> On 15 April 2018 at 01:45, Cillian O'Donnell 
> wrote:
>
>> Switch one of these lines out in qemu.cfg.
>>
>> #%define qemu_opts_base -no-reboot -monitor none -serial stdio -nographic
>> #%define qemu_opts_base -no-reboot -serial null -serial mon:stdio
>> -nographic
>> %define qemu_opts_base -no-reboot -monitor null -serial stdio -nographic
>>
>> Just comment out the one that's being used and uncomment one of the
>> others. It should cause a complaint when the tests are run and the qemu cmd
>> should show up in the log so we can take a look at it.
>>
>
>
> error: qemu.cfg:71: execute failed: qemu-system-sparc -no-reboot -monitor
> null -serial stdio -nographic -no-reboot -monitor null -serial stdio
> -nographic -M leon3_generic -kernel /home/lunatic/development/
> rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/
> samples/unlimited/unlimited.exe: exit-code:1
>
> run: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic
> -no-reboot -monitor null -serial stdio -nographic -M leon3_generic
> -kernel /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/
> leon3/testsuites/samples/unlimited/unlimited.exe -exec-trace
>  /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe.cov
>

Are those line breaks actually there or is it from the copy and paste.
Like  unlimited. If so that's definitely the problem. What does your
last section in qemu.cfg look like now? The execute section.

>
>
>
>
>
>>
>> On 14 April 2018 at 20:37, Vijay Kumar Banerjee > > wrote:
>>
>>>
>>>
>>> -- vijay
>>>
>>> On 15 April 2018 at 00:50, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 14 April 2018 at 16:42, Cillian O'Donnell 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 14 April 2018 at 07:11, Chris Johns  wrote:
>>>>>
>>>>>> On 14/4/18 8:02 am, Vijay Kumar Banerjee wrote:
>>>>>>
>>>>>>> Getting this error now seems like something is missing.
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>> RTEMS Testing - Tester, 5 (b2ba08b0da42 modified)
>>>>>>> Coverage environment prepared
>>>>>>> Traceback (most recent call last):
>>>>>>>File 
>>>>>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rtems-test",
>>>>>>> line 40, in 
>>>>>>>  rt.test.run()
>>>>>>>File 
>>>>>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py",
>>>>>>> line 353, in run
>>>>>>>  tst.reraise()
>>>>>>>File 
>>>>>>> "/home/lunatic/development/rtems/test/rtems-tools/tester/rt/test.py",
>>>>>>> line 160, in reraise
>>>>>>>  _test_reraise(*self.result)
>>>>>>> NameError: global name '_test_reraise' is not defined
>>>>>>>
>>>>>>>
>>>>>> The reraise logic was moved to the rtemstoolkit last year:
>>>>>>
>>>>>> https://git.rtems.org/rtems-tools/commit/?id=fa81491764861e6
>>>>>> 3785a3faa241c488469087209
>>>>>>
>>>>>> It had some issues that have been fixed and it is being reused else
>>>>>> where in the tester.
>>>>>>
>>>>>>
>>>>>>> -- vijay
>>>>>>>
>>>>>>> On 13 April 2018 at 23:57, Vijay Kumar Banerjee <
>>>>>>> vijaykumar9...@gmail.com <mailto:vijaykumar9...@gmail.com>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 13 April 2018 at 23:51, Cillian O'Donnell <
>>>>>>> cpodonne...@gmail.com
>>>>>>> <mailto:cpodonne...@gmail.com>> wrote:
>>>>>>>
>>>>>>> Hmmm it's not there. Even so I can almost guarantee you, the
>>>>>>> reason it's not running is that coverage_supported variable
>>>>>>> is
>>>>>>> not bei

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

Not sure what's happening there. Send me a link to your github branch.

On 15 April 2018 at 09:35, Vijay Kumar Banerjee 
wrote:

>
>
> On 15 April 2018 at 14:02, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 15 April 2018 at 06:46, Vijay Kumar Banerjee > > wrote:
>>
>>>
>>>
>>> On 15 April 2018 at 01:45, Cillian O'Donnell 
>>> wrote:
>>>
>>>> Switch one of these lines out in qemu.cfg.
>>>>
>>>> #%define qemu_opts_base -no-reboot -monitor none -serial stdio
>>>> -nographic
>>>> #%define qemu_opts_base -no-reboot -serial null -serial mon:stdio
>>>> -nographic
>>>> %define qemu_opts_base -no-reboot -monitor null -serial stdio -nographic
>>>>
>>>> Just comment out the one that's being used and uncomment one of the
>>>> others. It should cause a complaint when the tests are run and the qemu cmd
>>>> should show up in the log so we can take a look at it.
>>>>
>>>
>>>
>>> error: qemu.cfg:71: execute failed: qemu-system-sparc -no-reboot
>>> -monitor null -serial stdio -nographic -no-reboot -monitor null -serial
>>> stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtem
>>> s/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe:
>>> exit-code:1
>>>
>>> run: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic
>>> -no-reboot -monitor null -serial stdio -nographic -M leon3_generic
>>> -kernel /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/
>>> leon3/testsuites/samples/unlimited/unlimited.exe -exec-trace
>>>  /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c
>>> /leon3/testsuites/samples/unlimited/unlimited.exe.cov
>>>
>>
>> Are those line breaks actually there or is it from the copy and paste.
>> Like  unlimited. If so that's definitely the problem. What does your
>> last section in qemu.cfg look like now? The execute section.
>>
> They are from copy paste .
> I'm pasting the qemu.cfg here
> .
>
> #
> # RTEMS Tools Project (http://www.rtems.org/)
> # Copyright 2010-2014 Chris Johns (chr...@rtems.org)
> # All rights reserved.
> #
> # This file is part of the RTEMS Tools package in 'rtems-tools'.
> #
> # Redistribution and use in source and binary forms, with or without
> # modification, are permitted provided that the following conditions are
> met:
> #
> # 1. Redistributions of source code must retain the above copyright notice,
> # this list of conditions and the following disclaimer.
> #
> # 2. Redistributions in binary form must reproduce the above copyright
> notice,
> # this list of conditions and the following disclaimer in the documentation
> # and/or other materials provided with the distribution.
> #
> # this software is provided by the copyright holders and contributors "as
> is"
> # and any express or implied warranties, including, but not limited to, the
> # implied warranties of merchantability and fitness for a particular
> purpose
> # are disclaimed. in no event shall the copyright holder or contributors be
> # liable for any direct, indirect, incidental, special, exemplary, or
> # consequential damages (including, but not limited to, procurement of
> # substitute goods or services; loss of use, data, or profits; or business
> # interruption) however caused and on any theory of liability, whether in
> # contract, strict liability, or tort (including negligence or otherwise)
> # arising in any way out of the use of this software, even if advised of
> the
> # possibility of such damage.
> #
>
> #
> # qemu
> #
> # use a qemu command to run the executable in the qemu simulator.
> #
>
> %include %{_configdir}/base.cfg
> %include %{_configdir}/checks.cfg
>
> #
> # console.
> #
> %define console_stdio
> %include %{_configdir}/console.cfg
>
> #
> # rtems version
> #
> %include %{_rtdir}/rtems/version.cfg
>
> #
> # qemu common option patterns.
> #
> %define qemu_opts_base   -no-reboot -monitor none -serial stdio -nographic
> #%define qemu_opts_base   -no-reboot -serial null -serial mon:stdio
> -nographic
> #%define qemu_opts_base  -no-reboot -monitor null -serial stdio -nographic
> %define qemu_opts_no_net -net none
> #
> # qemu executable
> #
> %ifn %{defined bsp_qemu_opts}
>  %define bsp_qemu_opts %{nil}
> %endif
> %define qemu_cmd  qemu-system-%{bsp_arch}
> %define qemu_opts %{bsp_qemu_opts}
>
>
> #
> # Coverage an

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

On 15 April 2018 at 10:09, Cillian O'Donnell  wrote:

> Not sure what's happening there. Send me a link to your github branch.
>
> On 15 April 2018 at 09:35, Vijay Kumar Banerjee 
> wrote:
>
>>
>>
>> On 15 April 2018 at 14:02, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 15 April 2018 at 06:46, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On 15 April 2018 at 01:45, Cillian O'Donnell 
>>>> wrote:
>>>>
>>>>> Switch one of these lines out in qemu.cfg.
>>>>>
>>>>> #%define qemu_opts_base -no-reboot -monitor none -serial stdio
>>>>> -nographic
>>>>> #%define qemu_opts_base -no-reboot -serial null -serial mon:stdio
>>>>> -nographic
>>>>> %define qemu_opts_base -no-reboot -monitor null -serial stdio
>>>>> -nographic
>>>>>
>>>>> Just comment out the one that's being used and uncomment one of the
>>>>> others. It should cause a complaint when the tests are run and the qemu 
>>>>> cmd
>>>>> should show up in the log so we can take a look at it.
>>>>>
>>>>
>>>>
>>>> error: qemu.cfg:71: execute failed: qemu-system-sparc -no-reboot
>>>> -monitor null -serial stdio -nographic -no-reboot -monitor null -serial
>>>> stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtem
>>>> s/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe:
>>>> exit-code:1
>>>>
>>>> run: qemu-system-sparc -no-reboot -monitor null -serial stdio
>>>> -nographic -no-reboot -monitor null -serial stdio -nographic -M
>>>> leon3_generic -kernel /home/lunatic/development/rtem
>>>> s/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe
>>>> -exec-trace /home/lunatic/development/rte
>>>> ms/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimi
>>>> ted/unlimited.exe.cov
>>>>
>>>
>>> Are those line breaks actually there or is it from the copy and paste.
>>> Like  unlimited. If so that's definitely the problem. What does your
>>> last section in qemu.cfg look like now? The execute section.
>>>
>> They are from copy paste .
>> I'm pasting the qemu.cfg here
>> .
>>
>> #
>> # RTEMS Tools Project (http://www.rtems.org/)
>> # Copyright 2010-2014 Chris Johns (chr...@rtems.org)
>> # All rights reserved.
>> #
>> # This file is part of the RTEMS Tools package in 'rtems-tools'.
>> #
>> # Redistribution and use in source and binary forms, with or without
>> # modification, are permitted provided that the following conditions are
>> met:
>> #
>> # 1. Redistributions of source code must retain the above copyright
>> notice,
>> # this list of conditions and the following disclaimer.
>> #
>> # 2. Redistributions in binary form must reproduce the above copyright
>> notice,
>> # this list of conditions and the following disclaimer in the
>> documentation
>> # and/or other materials provided with the distribution.
>> #
>> # this software is provided by the copyright holders and contributors "as
>> is"
>> # and any express or implied warranties, including, but not limited to,
>> the
>> # implied warranties of merchantability and fitness for a particular
>> purpose
>> # are disclaimed. in no event shall the copyright holder or contributors
>> be
>> # liable for any direct, indirect, incidental, special, exemplary, or
>> # consequential damages (including, but not limited to, procurement of
>> # substitute goods or services; loss of use, data, or profits; or business
>> # interruption) however caused and on any theory of liability, whether in
>> # contract, strict liability, or tort (including negligence or otherwise)
>> # arising in any way out of the use of this software, even if advised of
>> the
>> # possibility of such damage.
>> #
>>
>> #
>> # qemu
>> #
>> # use a qemu command to run the executable in the qemu simulator.
>> #
>>
>> %include %{_configdir}/base.cfg
>> %include %{_configdir}/checks.cfg
>>
>> #
>> # console.
>> #
>> %define console_stdio
>> %include %{_configdir}/console.cfg
>>
>> #
>> # rtems version
>> #
>> %include %{_rtd

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

Probably what'll happen is, when the reports are generating properly, Chris
will review the changes and come up with a list of blockers that must be
fixed before he would be happy accepting the code into rtems-tools master.
Then when that's done you can submit the patches.

The thing with the data missing from the reports is tricky because there's
no error messages or log output to go on. Last time I seen that it was
because we were changing how the symbols were parsed and they were being
chopped up in odd ways and so none of them were found and so the report was
empty. This time I'm not sure because we haven't changed anything like
that. If I think of any clues, I'll let you know.

On Mon, 16 Apr 2018, 05:36 Vijay Kumar Banerjee, 
wrote:

>
>
> On 15 April 2018 at 15:33, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 15 April 2018 at 10:09, Cillian O'Donnell 
>> wrote:
>>
>>> Not sure what's happening there. Send me a link to your github branch.
>>>
>>> On 15 April 2018 at 09:35, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On 15 April 2018 at 14:02, Cillian O'Donnell 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 15 April 2018 at 06:46, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 15 April 2018 at 01:45, Cillian O'Donnell 
>>>>>> wrote:
>>>>>>
>>>>>>> Switch one of these lines out in qemu.cfg.
>>>>>>>
>>>>>>> #%define qemu_opts_base -no-reboot -monitor none -serial stdio
>>>>>>> -nographic
>>>>>>> #%define qemu_opts_base -no-reboot -serial null -serial mon:stdio
>>>>>>> -nographic
>>>>>>> %define qemu_opts_base -no-reboot -monitor null -serial stdio
>>>>>>> -nographic
>>>>>>>
>>>>>>> Just comment out the one that's being used and uncomment one of the
>>>>>>> others. It should cause a complaint when the tests are run and the qemu 
>>>>>>> cmd
>>>>>>> should show up in the log so we can take a look at it.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> error: qemu.cfg:71: execute failed: qemu-system-sparc -no-reboot
>>>>>> -monitor null -serial stdio -nographic -no-reboot -monitor null -serial
>>>>>> stdio -nographic -M leon3_generic -kernel
>>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe:
>>>>>> exit-code:1
>>>>>>
>>>>>> run: qemu-system-sparc -no-reboot -monitor null -serial stdio
>>>>>> -nographic -no-reboot -monitor null -serial stdio -nographic -M
>>>>>> leon3_generic -kernel /home/lunatic/development/rtem
>>>>>> s/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe
>>>>>> -exec-trace
>>>>>>  
>>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimi
>>>>>>   ted/unlimited.exe.cov
>>>>>>
>>>>>
>>>>> Are those line breaks actually there or is it from the copy and paste.
>>>>> Like  unlimited. If so that's definitely the problem. What does your
>>>>> last section in qemu.cfg look like now? The execute section.
>>>>>
>>>> They are from copy paste .
>>>> I'm pasting the qemu.cfg here
>>>> .
>>>>
>>>> #
>>>> # RTEMS Tools Project (http://www.rtems.org/)
>>>> # Copyright 2010-2014 Chris Johns (chr...@rtems.org)
>>>> # All rights reserved.
>>>> #
>>>> # This file is part of the RTEMS Tools package in 'rtems-tools'.
>>>> #
>>>> # Redistribution and use in source and binary forms, with or without
>>>> # modification, are permitted provided that the following conditions
>>>> are met:
>>>> #
>>>> # 1. Redistributions of source code must retain the above copyright
>>>> notice,
>>>> # this list of conditions and the following disclaimer.
>>>> #
>>>> # 2. Redistributions in binary form must reproduce the above copyright
>

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

I don't have a screen shot of it. If you firefox report.html and have a
look, all the bits that are NaN and all that will be filled with a
percentage coverage for all symbol sets tested (the only set in
symbol-sets.cfg is score at the moment so the coverage will be the tests
that were run on that set) it should be fairly obvious when it has worked,
there'll actually be something decent to look at so you'll probably know it
when you see it.

On Mon, 16 Apr 2018, 08:05 Vijay Kumar Banerjee, 
wrote:

> Ok thanks, so now we need to look into covoar.
> Do you have any sample output that will give me an idea of what it should
> look like ?
>
> On Mon, 16 Apr 2018, 11:13 Cillian O'Donnell, 
> wrote:
>
>> Probably what'll happen is, when the reports are generating properly,
>> Chris will review the changes and come up with a list of blockers that must
>> be fixed before he would be happy accepting the code into rtems-tools
>> master. Then when that's done you can submit the patches.
>>
>> The thing with the data missing from the reports is tricky because
>> there's no error messages or log output to go on. Last time I seen that it
>> was because we were changing how the symbols were parsed and they were
>> being chopped up in odd ways and so none of them were found and so the
>> report was empty. This time I'm not sure because we haven't changed
>> anything like that. If I think of any clues, I'll let you know.
>>
>> On Mon, 16 Apr 2018, 05:36 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On 15 April 2018 at 15:33, Cillian O'Donnell 
>>> wrote:
>>>
>>>>
>>>>
>>>> On 15 April 2018 at 10:09, Cillian O'Donnell 
>>>> wrote:
>>>>
>>>>> Not sure what's happening there. Send me a link to your github branch.
>>>>>
>>>>> On 15 April 2018 at 09:35, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 15 April 2018 at 14:02, Cillian O'Donnell 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 15 April 2018 at 06:46, Vijay Kumar Banerjee <
>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15 April 2018 at 01:45, Cillian O'Donnell >>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Switch one of these lines out in qemu.cfg.
>>>>>>>>>
>>>>>>>>> #%define qemu_opts_base -no-reboot -monitor none -serial stdio
>>>>>>>>> -nographic
>>>>>>>>> #%define qemu_opts_base -no-reboot -serial null -serial mon:stdio
>>>>>>>>> -nographic
>>>>>>>>> %define qemu_opts_base -no-reboot -monitor null -serial stdio
>>>>>>>>> -nographic
>>>>>>>>>
>>>>>>>>> Just comment out the one that's being used and uncomment one of
>>>>>>>>> the others. It should cause a complaint when the tests are run and 
>>>>>>>>> the qemu
>>>>>>>>> cmd should show up in the log so we can take a look at it.
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> error: qemu.cfg:71: execute failed: qemu-system-sparc -no-reboot
>>>>>>>> -monitor null -serial stdio -nographic -no-reboot -monitor null -serial
>>>>>>>> stdio -nographic -M leon3_generic -kernel
>>>>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe:
>>>>>>>> exit-code:1
>>>>>>>>
>>>>>>>> run: qemu-system-sparc -no-reboot -monitor null -serial stdio
>>>>>>>> -nographic -no-reboot -monitor null -serial stdio -nographic -M
>>>>>>>> leon3_generic -kernel /home/lunatic/development/rtem
>>>>>>>> s/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe
>>>>>>>> -exec-trace
>>>>>>>>  
>>>>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtem

Re: error while running rtems-test with coverage

[Cillian O'Donnell]

Yup good idea.

On Mon, 16 Apr 2018, 08:23 Vijay Kumar Banerjee, 
wrote:

> the coverage is running now, shall we start a new mail thread for
> covoar report ?
>
> -- vijay
>
> On 16 April 2018 at 12:35, Vijay Kumar Banerjee 
> wrote:
>
>> Ok thanks, so now we need to look into covoar.
>> Do you have any sample output that will give me an idea of what it should
>> look like ?
>>
>> On Mon, 16 Apr 2018, 11:13 Cillian O'Donnell, 
>> wrote:
>>
>>> Probably what'll happen is, when the reports are generating properly,
>>> Chris will review the changes and come up with a list of blockers that must
>>> be fixed before he would be happy accepting the code into rtems-tools
>>> master. Then when that's done you can submit the patches.
>>>
>>> The thing with the data missing from the reports is tricky because
>>> there's no error messages or log output to go on. Last time I seen that it
>>> was because we were changing how the symbols were parsed and they were
>>> being chopped up in odd ways and so none of them were found and so the
>>> report was empty. This time I'm not sure because we haven't changed
>>> anything like that. If I think of any clues, I'll let you know.
>>>
>>> On Mon, 16 Apr 2018, 05:36 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On 15 April 2018 at 15:33, Cillian O'Donnell 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 15 April 2018 at 10:09, Cillian O'Donnell 
>>>>> wrote:
>>>>>
>>>>>> Not sure what's happening there. Send me a link to your github branch.
>>>>>>
>>>>>> On 15 April 2018 at 09:35, Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 15 April 2018 at 14:02, Cillian O'Donnell 
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15 April 2018 at 06:46, Vijay Kumar Banerjee <
>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 15 April 2018 at 01:45, Cillian O'Donnell <
>>>>>>>>> cpodonne...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Switch one of these lines out in qemu.cfg.
>>>>>>>>>>
>>>>>>>>>> #%define qemu_opts_base -no-reboot -monitor none -serial stdio
>>>>>>>>>> -nographic
>>>>>>>>>> #%define qemu_opts_base -no-reboot -serial null -serial
>>>>>>>>>> mon:stdio -nographic
>>>>>>>>>> %define qemu_opts_base -no-reboot -monitor null -serial stdio
>>>>>>>>>> -nographic
>>>>>>>>>>
>>>>>>>>>> Just comment out the one that's being used and uncomment one of
>>>>>>>>>> the others. It should cause a complaint when the tests are run and 
>>>>>>>>>> the qemu
>>>>>>>>>> cmd should show up in the log so we can take a look at it.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> error: qemu.cfg:71: execute failed: qemu-system-sparc -no-reboot
>>>>>>>>> -monitor null -serial stdio -nographic -no-reboot -monitor null 
>>>>>>>>> -serial
>>>>>>>>> stdio -nographic -M leon3_generic -kernel
>>>>>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe:
>>>>>>>>> exit-code:1
>>>>>>>>>
>>>>>>>>> run: qemu-system-sparc -no-reboot -monitor null -serial stdio
>>>>>>>>> -nographic -no-reboot -monitor null -serial stdio -nographic -M
>>>>>>>>> leon3_generic -kernel /home/lunatic/development/rtem
>>>>>>>>> s/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.exe
>>>>>>>>> -exec-trace
>>

Re: the generated coverage report doesn't contain any data

[Cillian O'Donnell]

On 16 April 2018 at 17:46, Joel Sherrill  wrote:

>
>
> On Mon, Apr 16, 2018 at 2:33 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> current status :
>> the coverage is running now with rtems-test and generating the report,
>> however, the report doesn't show any data.
>>
>
> I've been lurking as you have been making progress. Now you have crossed
> into something you probably need some hints at. Some things to check:
>
> + Obviously, check output for signs that something didn't happen right.
> Anything from a path wrong, etc. The configuration has to be right to
> point to the source code, object code, executables, etc.
>
> + A lot of source code has moved around since last summer. Check
> that it is looking in the right places inside RTEMS.
>
> + Does the mechanism to get debug information actually work? Cillian?
>

The covoar debug option just disables the cleaning of the tempfiles to take
a look, so it's not as powerful as it might seem :)... I always used gdb
here so that's probably the way to go.

>
> + There is a utility named trace-converter. Make sure your qemu traces
> have information in them.
>
> + Cillian probably has guidance on running it just on one test (say ticker)
> so you can see every step.
>
> + Check that the executables have symbolic information. "file" should
> show if they are stripped or not.
>
> I recall covoar has a verbose mode which should be of use.
>
> Cillian .. do you have instructions on running covoar in gdb?
>

Alright so run rtems-test with --no-clean option to leave the coverage
files lying around

$HOME/development/rtems/test/test/rtems-tools/tester/rtems-test
--rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
--rtems-bsp=leon3_qemu --coverage --no-clean
--rtems-builddir=$HOME/development/rtems/leon3
sparc-rtems5/c/leon3/testsuites/samples

Then run

gdb covoar

from gdb prompt

run -S /home/cpod/coverage_test/leon3/coverage/score.symcfg -O
/home/cpod/coverage_test/leon3/test/score -fQEMU -Tsparc-rtems5
-E/home/cpod/development/rtems/test/test/vijay/rtems-tools/tester/rtems/testing/coverage/Explanations.txt
-c.cov -eexe -pRTEMS-5
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe

The options there are ( if you're wondering )

 -c COVERAGEFILE_EXTENSION EXECUTABLE1 ... EXECUTABLE2

 -v  - verbose output
 -T TARGET   - architecture target name
 -f FORMAT   - simulator format
(RTEMS, QEMU, TSIM or Skyeye)
 -E EXPLANATIONS - file of explanations
 -s SYMBOLS_FILE - symbols of interest
 -S SYMBOL_SET_FILE  - path to symbol_sets.cfg
 -1 EXECUTABLE   - executable to get symbols from
 -e EXE_EXTENSION- suffix for executables
 -c COVERAGEFILE_EXT - coverage file suffix
 -g GCNOS_LIST   - list of *.gcno files
 -p PROJECT_NAME - name of the project
 -O Output_Directory - output directory default=.
 -d debug- disable cleaning of tempfiles.

Just trying it there, it runs into segmentation fault. So trying to access
memory it shouldn't.

Starting program: /home/cpod/covoar -S
/home/cpod/coverage_test/leon3/coverage/score.symcfg -O
/home/cpod/coverage_test/leon3/test/score -fQEMU -Tsparc-rtems5
-E/home/cpod/development/rtems/test/test/vijay/rtems-tools/tester/rtems/testing/coverage/Explanations.txt
-c.cov -eexe -pRTEMS-5
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe
Reading configuration symbol set file:
/home/cpod/coverage_test/leon3/coverage/score.symcfg

Program received signal SIGSEGV, Segmentation fault.
0x77b769bb in std::__cxx11::basic_string, std::allocator
>::basic_string(std::__cxx11::basic_string,
std::allocator > const&) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

Ahhh feels good to have error messages back.

Oh also build covoar with no optimization and you'll have an easier time
looking at stuff in gdb

cd rtems-tools/tester/covoar

vim wscript and change the '-O2' to '-O0' and then build again with waf and
use that covoar to with gdb


>
>
>>
>> -- vijay
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: the generated coverage report doesn't contain any data

[Cillian O'Donnell]

Some things are definitely missing there. Git checkout main.c
coverage-merge. If you have that branch lying around, that definitely has
everything in it. I must of missed of some things updating to current
master. Fingers crossed this solves our problems


On Mon, 16 Apr 2018, 22:52 Vijay Kumar Banerjee, 
wrote:

>
>
> On Tue, 17 Apr 2018, 03:19 Joel Sherrill,  wrote:
>
>>
>>
>> On Mon, Apr 16, 2018 at 4:47 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On 17 April 2018 at 01:43, Cillian O'Donnell 
>>> wrote:
>>>
>>>>
>>>>
>>>> On 16 April 2018 at 17:46, Joel Sherrill  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 16, 2018 at 2:33 AM, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> current status :
>>>>>> the coverage is running now with rtems-test and generating the
>>>>>> report, however, the report doesn't show any data.
>>>>>>
>>>>>
>>>>> I've been lurking as you have been making progress. Now you have
>>>>> crossed
>>>>> into something you probably need some hints at. Some things to check:
>>>>>
>>>>> + Obviously, check output for signs that something didn't happen right.
>>>>> Anything from a path wrong, etc. The configuration has to be right to
>>>>> point to the source code, object code, executables, etc.
>>>>>
>>>>> + A lot of source code has moved around since last summer. Check
>>>>> that it is looking in the right places inside RTEMS.
>>>>>
>>>>> + Does the mechanism to get debug information actually work? Cillian?
>>>>>
>>>>
>>>> The covoar debug option just disables the cleaning of the tempfiles to
>>>> take a look, so it's not as powerful as it might seem :)... I always used
>>>> gdb here so that's probably the way to go.
>>>>
>>>>>
>>>>> + There is a utility named trace-converter. Make sure your qemu traces
>>>>> have information in them.
>>>>>
>>>>> + Cillian probably has guidance on running it just on one test (say
>>>>> ticker)
>>>>> so you can see every step.
>>>>>
>>>>> + Check that the executables have symbolic information. "file" should
>>>>> show if they are stripped or not.
>>>>>
>>>>> I recall covoar has a verbose mode which should be of use.
>>>>>
>>>>> Cillian .. do you have instructions on running covoar in gdb?
>>>>>
>>>>
>>>> Alright so run rtems-test with --no-clean option to leave the coverage
>>>> files lying around
>>>>
>>>> $HOME/development/rtems/test/test/rtems-tools/tester/rtems-test
>>>> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
>>>> --rtems-bsp=leon3_qemu --coverage --no-clean
>>>> --rtems-builddir=$HOME/development/rtems/leon3
>>>> sparc-rtems5/c/leon3/testsuites/samples
>>>>
>>>> Then run
>>>>
>>>> gdb covoar
>>>>
>>>> from gdb prompt
>>>>
>>>> run -S /home/cpod/coverage_test/leon3/coverage/score.symcfg -O
>>>> /home/cpod/coverage_test/leon3/test/score -fQEMU -Tsparc-rtems5
>>>> -E/home/cpod/development/rtems/test/test/vijay/rtems-tools/tester/rtems/testing/coverage/Explanations.txt
>>>> -c.cov -eexe -pRTEMS-5
>>>> /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe
>>>>
>>>> The options there are ( if you're wondering )
>>>>
>>>>  -c COVERAGEFILE_EXTENSION EXECUTABLE1 ... EXECUTABLE2
>>>>
>>>>  -v  - verbose output
>>>>  -T TARGET   - architecture target name
>>>>  -f FORMAT   - simulator format
>>>> (RTEMS, QEMU, TSIM or Skyeye)
>>>>  -E EXPLANATIONS - file of explanations
>>>>  -s SYMBOLS_FILE - symbols of interest
>>>>  -S SYMBOL_SET_FILE  - path to symbol_sets.cfg
>>>>  -1 EXECUTABLE   - executable to get symbols from
>>>>  -e EXE_EXTENSION- suffix for executables
>>>>  -c COVERAGEFILE_EXT - coverage file suffix
>>>>  -g GCNOS_LIST

Re: the generated coverage report doesn't contain any data

[Cillian O'Donnell]

Also if there's any file in covoar directory of coverage-merge branch
that's called symbol-set.c symbol_set_reader.h or any variation of that,
that you don't already have pull all of them into your current branch.

On Tue, 17 Apr 2018, 07:19 Cillian O'Donnell,  wrote:

> Some things are definitely missing there. Git checkout main.c
> coverage-merge. If you have that branch lying around, that definitely has
> everything in it. I must of missed of some things updating to current
> master. Fingers crossed this solves our problems
>
>
> On Mon, 16 Apr 2018, 22:52 Vijay Kumar Banerjee, 
> wrote:
>
>>
>>
>> On Tue, 17 Apr 2018, 03:19 Joel Sherrill,  wrote:
>>
>>>
>>>
>>> On Mon, Apr 16, 2018 at 4:47 PM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On 17 April 2018 at 01:43, Cillian O'Donnell 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 16 April 2018 at 17:46, Joel Sherrill  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 16, 2018 at 2:33 AM, Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> current status :
>>>>>>> the coverage is running now with rtems-test and generating the
>>>>>>> report, however, the report doesn't show any data.
>>>>>>>
>>>>>>
>>>>>> I've been lurking as you have been making progress. Now you have
>>>>>> crossed
>>>>>> into something you probably need some hints at. Some things to check:
>>>>>>
>>>>>> + Obviously, check output for signs that something didn't happen
>>>>>> right.
>>>>>> Anything from a path wrong, etc. The configuration has to be right to
>>>>>> point to the source code, object code, executables, etc.
>>>>>>
>>>>>> + A lot of source code has moved around since last summer. Check
>>>>>> that it is looking in the right places inside RTEMS.
>>>>>>
>>>>>> + Does the mechanism to get debug information actually work? Cillian?
>>>>>>
>>>>>
>>>>> The covoar debug option just disables the cleaning of the tempfiles to
>>>>> take a look, so it's not as powerful as it might seem :)... I always used
>>>>> gdb here so that's probably the way to go.
>>>>>
>>>>>>
>>>>>> + There is a utility named trace-converter. Make sure your qemu traces
>>>>>> have information in them.
>>>>>>
>>>>>> + Cillian probably has guidance on running it just on one test (say
>>>>>> ticker)
>>>>>> so you can see every step.
>>>>>>
>>>>>> + Check that the executables have symbolic information. "file" should
>>>>>> show if they are stripped or not.
>>>>>>
>>>>>> I recall covoar has a verbose mode which should be of use.
>>>>>>
>>>>>> Cillian .. do you have instructions on running covoar in gdb?
>>>>>>
>>>>>
>>>>> Alright so run rtems-test with --no-clean option to leave the coverage
>>>>> files lying around
>>>>>
>>>>> $HOME/development/rtems/test/test/rtems-tools/tester/rtems-test
>>>>> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
>>>>> --rtems-bsp=leon3_qemu --coverage --no-clean
>>>>> --rtems-builddir=$HOME/development/rtems/leon3
>>>>> sparc-rtems5/c/leon3/testsuites/samples
>>>>>
>>>>> Then run
>>>>>
>>>>> gdb covoar
>>>>>
>>>>> from gdb prompt
>>>>>
>>>>> run -S /home/cpod/coverage_test/leon3/coverage/score.symcfg -O
>>>>> /home/cpod/coverage_test/leon3/test/score -fQEMU -Tsparc-rtems5
>>>>> -E/home/cpod/development/rtems/test/test/vijay/rtems-tools/tester/rtems/testing/coverage/Explanations.txt
>>>>> -c.cov -eexe -pRTEMS-5
>>>>> /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe
>>>>>
>>>>> The options there are ( if you're wondering )
>>>>>
>>>>>  -c CO

Re: the generated coverage report doesn't contain any data

[Cillian O'Donnell]

Could be still missing something, try using the whole covoar directory from
coverage-merge. I spent a good bit of time fixing errors like that, would
be strange if it popped back up again but it could be right. Either way
we're in pretty good shape now. Report looks good, try and run it with the
full testsuite to see what happens, it takes a while, a hour-ish.

On 17 April 2018 at 20:32, Vijay Kumar Banerjee 
wrote:

>
>
>
> On 18 April 2018 at 00:57, Vijay Kumar Banerjee 
> wrote:
>
>> The report is showing some data !!
>>
>> I merged a lot of changes form coverage-merge , it's showing some data
>> now , but I'm still getting a set of errors. I'll paste them below.
>>
>> I have attached a screenshot of the report.html
>>
>> errors :
>> 
>> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
>> coverage maps for _Workspace_Allocate_or_fatal_error with different
>> sizes (/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/
>> c/leon3/testsuites/samples/capture/capture.exe/84 !=
>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/
>> leon3/testsuites/samples/base_sp/base_sp.exe/60)
>>
>> INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map
>> for _Workspace_Allocate_or_fatal_error because the sizes are different
>>
>> Am I still possibly missing something ?
>
>>
>>
> On 17 April 2018 at 11:59, Cillian O'Donnell 
>> wrote:
>>
>>> Also if there's any file in covoar directory of coverage-merge branch
>>> that's called symbol-set.c symbol_set_reader.h or any variation of that,
>>> that you don't already have pull all of them into your current branch.
>>>
>>> On Tue, 17 Apr 2018, 07:19 Cillian O'Donnell, 
>>> wrote:
>>>
>>>> Some things are definitely missing there. Git checkout main.c
>>>> coverage-merge. If you have that branch lying around, that definitely has
>>>> everything in it. I must of missed of some things updating to current
>>>> master. Fingers crossed this solves our problems
>>>>
>>>>
>>>> On Mon, 16 Apr 2018, 22:52 Vijay Kumar Banerjee, <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, 17 Apr 2018, 03:19 Joel Sherrill,  wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 16, 2018 at 4:47 PM, Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 17 April 2018 at 01:43, Cillian O'Donnell 
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 16 April 2018 at 17:46, Joel Sherrill  wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Apr 16, 2018 at 2:33 AM, Vijay Kumar Banerjee <
>>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> current status :
>>>>>>>>>> the coverage is running now with rtems-test and generating the
>>>>>>>>>> report, however, the report doesn't show any data.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've been lurking as you have been making progress. Now you have
>>>>>>>>> crossed
>>>>>>>>> into something you probably need some hints at. Some things to
>>>>>>>>> check:
>>>>>>>>>
>>>>>>>>> + Obviously, check output for signs that something didn't happen
>>>>>>>>> right.
>>>>>>>>> Anything from a path wrong, etc. The configuration has to be right
>>>>>>>>> to
>>>>>>>>> point to the source code, object code, executables, etc.
>>>>>>>>>
>>>>>>>>> + A lot of source code has moved around since last summer. Check
>>>>>>>>> that it is looking in the right places inside RTEMS.
>>>>>>>>>
>>>>>>>>> + Does the mechanism to get debug information actually work?
>>>>>>>>> Cillian?
>>>>>>>>

Re: the generated coverage report doesn't contain any data

[Cillian O'Donnell]

Oh great!. So the coverage-merge branch worked. The stuff about symbol-sets
and a fix to get rid of a dependency of one of the external tools is all
that hasn't been merged there. Like Joel said there, try run it again with
covoar built with less optimization. The option is in covoar/wscript.

On Wed, 18 Apr 2018, 17:32 Joel Sherrill,  wrote:

>
>
> On Wed, Apr 18, 2018 at 10:49 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> It's great to see it produce some data .
>> I have attached a screenshot of the report generated from testsuites
>>
>
> It is good to see results. I have no idea about the "goodness" of them.
> That depends
> on the configuration, tests run, optimization level, etc. We normally use
> -Os for
> coverage analysis because -O2 unrolls loops and duplicates code. -Os has
> the
> generated code more closely match the source.
>
> I suppose the next step is to work to get Cillian's updated work merged.
>
> Then for me to try to duplicate the results.
>
> FWIW I am teaching an RTEMS class next week and won't be around as much.
>
> --joel
>
>
>>
>>
>>
>> On 18 April 2018 at 02:07, Cillian O'Donnell 
>> wrote:
>>
>>> Could be still missing something, try using the whole covoar directory
>>> from coverage-merge. I spent a good bit of time fixing errors like that,
>>> would be strange if it popped back up again but it could be right. Either
>>> way we're in pretty good shape now. Report looks good, try and run it with
>>> the full testsuite to see what happens, it takes a while, a hour-ish.
>>>
>>> On 17 April 2018 at 20:32, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 18 April 2018 at 00:57, Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> The report is showing some data !!
>>>>>
>>>>> I merged a lot of changes form coverage-merge , it's showing some data
>>>>> now , but I'm still getting a set of errors. I'll paste them below.
>>>>>
>>>>> I have attached a screenshot of the report.html
>>>>>
>>>>> errors :
>>>>> 
>>>>> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
>>>>> coverage maps for _Workspace_Allocate_or_fatal_error with different sizes
>>>>> (/home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture/capture.exe/84
>>>>> !=
>>>>> /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/60)
>>>>>
>>>>> INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map
>>>>> for _Workspace_Allocate_or_fatal_error because the sizes are different
>>>>>
>>>>> Am I still possibly missing something ?
>>>>
>>>>>
>>>>>
>>>> On 17 April 2018 at 11:59, Cillian O'Donnell 
>>>>> wrote:
>>>>>
>>>>>> Also if there's any file in covoar directory of coverage-merge branch
>>>>>> that's called symbol-set.c symbol_set_reader.h or any variation of that,
>>>>>> that you don't already have pull all of them into your current branch.
>>>>>>
>>>>>> On Tue, 17 Apr 2018, 07:19 Cillian O'Donnell, 
>>>>>> wrote:
>>>>>>
>>>>>>> Some things are definitely missing there. Git checkout main.c
>>>>>>> coverage-merge. If you have that branch lying around, that definitely 
>>>>>>> has
>>>>>>> everything in it. I must of missed of some things updating to current
>>>>>>> master. Fingers crossed this solves our problems
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 16 Apr 2018, 22:52 Vijay Kumar Banerjee, <
>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, 17 Apr 2018, 03:19 Joel Sherrill,  wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Apr 16, 2018 at 4:47 PM, Vijay Kumar Banerjee <
>>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>

[PATCH 0/2] *** Covoar Outstanding Changes ***

[Cillian O'Donnell]

*** ALright so here is everything that exists locally for covoar that 
 was never merged. It amounts to the symbol set reader and the ability
 to load the symbols in from the ELF data with the help of rtemstoolkit.
Also all the configuration files. Now I understand we might want to split 
these patches up a bit more, I'm just trying to give everyone a look at
what I have locally here. I'm not sure how much of this is superfluous 
with Chris's propesed changes but its a starting point for us to see
what we want to do with all this.***

Cillian O'Donnell (2):
  covoar: Add symbol set reader and ELF data parser to covoar.
  rtems-tools/../testing: Add configuration files for coverage analysis.

 tester/covoar/SymbolSet.cpp| 153 
 tester/covoar/SymbolSet.h  |  79 +
 tester/covoar/SymbolSetReader.cpp  |  82 +
 tester/covoar/SymbolSetReader.h|  34 
 tester/covoar/covoar.cc|  57 --
 tester/covoar/wscript  |   4 +-
 tester/rtems/testing/bsps/leon3_qemu.ini   |  52 ++
 tester/rtems/testing/coverage.ini  |  49 +
 tester/rtems/testing/coverage/Categories.txt   |  19 ++
 tester/rtems/testing/coverage/Explanations.txt |  35 
 .../coverage/SPARC-Annul-Slot-Explanation.txt  |  56 ++
 tester/rtems/testing/coverage/style.css| 197 +
 tester/rtems/testing/coverage/symbol_sets.cfg  |   3 +
 tester/rtems/testing/qemu.cfg  |  14 +-
 14 files changed, 822 insertions(+), 12 deletions(-)
 create mode 100644 tester/covoar/SymbolSet.cpp
 create mode 100644 tester/covoar/SymbolSet.h
 create mode 100644 tester/covoar/SymbolSetReader.cpp
 create mode 100644 tester/covoar/SymbolSetReader.h
 create mode 100644 tester/rtems/testing/bsps/leon3_qemu.ini
 create mode 100644 tester/rtems/testing/coverage.ini
 create mode 100644 tester/rtems/testing/coverage/Categories.txt
 create mode 100644 tester/rtems/testing/coverage/Explanations.txt
 create mode 100644 
tester/rtems/testing/coverage/SPARC-Annul-Slot-Explanation.txt
 create mode 100644 tester/rtems/testing/coverage/style.css
 create mode 100644 tester/rtems/testing/coverage/symbol_sets.cfg

-- 
2.7.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/2] rtems-tools/../testing: Add configuration files for coverage analysis.

[Cillian O'Donnell]

Co-author: Krzysztof Miesowicz 
Co-author: Vijay Kumar Banerjee 
---
 tester/rtems/testing/bsps/leon3_qemu.ini   |  52 ++
 tester/rtems/testing/coverage.ini  |  49 +
 tester/rtems/testing/coverage/Categories.txt   |  19 ++
 tester/rtems/testing/coverage/Explanations.txt |  35 
 .../coverage/SPARC-Annul-Slot-Explanation.txt  |  56 ++
 tester/rtems/testing/coverage/style.css| 197 +
 tester/rtems/testing/coverage/symbol_sets.cfg  |   3 +
 tester/rtems/testing/qemu.cfg  |  14 +-
 8 files changed, 424 insertions(+), 1 deletion(-)
 create mode 100644 tester/rtems/testing/bsps/leon3_qemu.ini
 create mode 100644 tester/rtems/testing/coverage.ini
 create mode 100644 tester/rtems/testing/coverage/Categories.txt
 create mode 100644 tester/rtems/testing/coverage/Explanations.txt
 create mode 100644 
tester/rtems/testing/coverage/SPARC-Annul-Slot-Explanation.txt
 create mode 100644 tester/rtems/testing/coverage/style.css
 create mode 100644 tester/rtems/testing/coverage/symbol_sets.cfg

diff --git a/tester/rtems/testing/bsps/leon3_qemu.ini 
b/tester/rtems/testing/bsps/leon3_qemu.ini
new file mode 100644
index 000..9888008
--- /dev/null
+++ b/tester/rtems/testing/bsps/leon3_qemu.ini
@@ -0,0 +1,52 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2010-2014 Chris Johns (chr...@rtems.org)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# 1. Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+#
+# 2. Redistributions in binary form must reproduce the above copyright notice,
+# this list of conditions and the following disclaimer in the documentation
+# and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+# POSSIBILITY OF SUCH DAMAGE.
+#
+
+#
+# The Leon 3 QEMU BSP
+#
+[global]
+coverage_supported   = 1
+bsp  = leon3_qemu
+[leon3_qemu]
+bsp   = leon3_qemu
+arch  = sparc
+tester= %{_rtscripts}/qemu.cfg
+bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
+
+
+[coverage]
+format   = QEMU
+target   = sparc-rtems5
+explanations = %{_rtscripts}/coverage/Explanations.txt
+coverage_extension   = .cov
+gcnos_file   = %{_rtscripts}/coverage/rtems.gcnos
+executable_extension = exe
+project_name = RTEMS-5
+report_format= html
diff --git a/tester/rtems/testing/coverage.ini 
b/tester/rtems/testing/coverage.ini
new file mode 100644
index 000..c1eef2e
--- /dev/null
+++ b/tester/rtems/testing/coverage.ini
@@ -0,0 +1,49 @@
+#
+# RTEMS Tools Project (http://www.rtems.org/)
+# Copyright 2010-2014 Chris Johns (chr...@rtems.org)
+# All rights reserved.
+#
+# This file is part of the RTEMS Tools package in 'rtems-tools'.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions are met:
+#
+# 1. Redistributions of source code must retain the above copyright notice,
+# this list of conditions and the following disclaimer.
+#
+# 2. Redistributions in binary form must reproduce the above copyright notice,
+# this list of conditions and the following disclaimer in the documentation
+# and/or other materials provided with the distribution.
+#
+# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+# ARISING IN A

[PATCH 1/2] covoar: Add symbol set reader and ELF data parser to covoar.

[Cillian O'Donnell]

Add ability to organize symbol sets of libraries in symbol_set.cfg
and then read them with covoar (Krzysztof Miesowicz))
Also the symbols are now loaded in from ELF data rather than relying
on nm.(Cillian O'Donnell)

Co-author:"Krzysztof Miesowicz "
---
 tester/covoar/SymbolSet.cpp   | 153 ++
 tester/covoar/SymbolSet.h |  79 
 tester/covoar/SymbolSetReader.cpp |  82 
 tester/covoar/SymbolSetReader.h   |  34 +
 tester/covoar/covoar.cc   |  57 +++---
 tester/covoar/wscript |   4 +-
 6 files changed, 398 insertions(+), 11 deletions(-)
 create mode 100644 tester/covoar/SymbolSet.cpp
 create mode 100644 tester/covoar/SymbolSet.h
 create mode 100644 tester/covoar/SymbolSetReader.cpp
 create mode 100644 tester/covoar/SymbolSetReader.h

diff --git a/tester/covoar/SymbolSet.cpp b/tester/covoar/SymbolSet.cpp
new file mode 100644
index 000..dfa0fa1
--- /dev/null
+++ b/tester/covoar/SymbolSet.cpp
@@ -0,0 +1,153 @@
+/*
+ * Copyright 2014 Krzysztof Miesowicz  (krzysztof.miesow...@gmail.com)
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright notice,
+ * this list of conditions and the following disclaimer.
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
+ * and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES  (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT  (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+
+#include "SymbolSet.h"
+
+#include "rld.h"
+#include "rld-process.h"
+#include "rld-symbols.h"
+#include "rld-files.h"
+
+namespace Symbols
+{
+  SymbolSet::SymbolSet ()
+  {
+  }
+
+  SymbolSet::~SymbolSet ()
+  {
+  }
+
+  std::string SymbolSet::parseElfDataLine (std::string line)
+  {
+std::string symbol = "";
+int funcStartPos = 64;
+if (line.find ("STT_FUNC") != std::string::npos)
+{
+  symbol = line.substr (funcStartPos);
+  symbol = symbol.substr (0, symbol.find (' '));
+}
+return symbol;
+  }
+
+  std::string SymbolSet::getLibname (std::string libPath)
+  {
+std::string libname = "", base = "", temp;
+size_t pos = libPath.find_last_of ('/');
+if (pos != std::string::npos)
+{
+  temp = libPath.substr (0, pos);
+  libname = libPath.substr (pos + 1);
+}
+pos = temp.find_last_of ('/');
+if (pos != std::string::npos)
+{
+  base = temp.substr (pos + 1);
+}
+return base + "/" + libname;
+  }
+
+  void SymbolSet::parseElfData (rld::process::tempfile& elfData,
+const std::string& lib)
+  {
+std::string line, symbol;
+elfData.open( true );
+while ( true )
+{
+  elfData.read_line (line);
+  if ( line.empty() ) break;
+  symbol = parseElfDataLine (line);
+  if (symbol.length () > 0)
+  {
+symbols.push_back (symbol + " " + getLibname (lib));
+  }
+}
+  }
+
+  void SymbolSet::generateSymbolFile (rld::process::tempfile& filePath,
+  std::string target)
+  {
+rld::files::cache   kernel;
+rld::symbols::table symbolsTable;
+
+for (std::string lib : libraries)
+{
+  /*
+   * Load the symbols from the kernel.
+   */
+  try
+  {
+/*
+ * Load the kernel ELF file symbol table.
+ */
+kernel.open ();
+kernel.add (lib);
+kernel.load_symbols (symbolsTable, true);
+
+/*
+ * Create a symbols file.
+ */
+std::ofstream mout;
+mout.open (filePath.name().c_str());
+if (!mout.is_open ())
+  throw rld::error ("map file open failed", "map");
+mout << "RTEMS Kernel Symbols Map" << std::endl
+   

Re: [PATCH 0/2] *** Covoar Outstanding Changes ***

[Cillian O'Donnell]

On Thu, 26 Apr 2018, 03:27 Chris Johns,  wrote:

> On 26/04/2018 06:33, Cillian O'Donnell wrote:
> > *** ALright so here is everything that exists locally for covoar that
> >  was never merged. It amounts to the symbol set reader and the ability
> >  to load the symbols in from the ELF data with the help of rtemstoolkit.
> > Also all the configuration files. Now I understand we might want to
> split
> > these patches up a bit more, I'm just trying to give everyone a look at
> > what I have locally here. I'm not sure how much of this is superfluous
> > with Chris's propesed changes but its a starting point for us to see
> > what we want to do with all this.***
>
> Thank you for posting these patches.
>
> I am reviewing these changes and I think they will fit in. I will come
> back once
> I have a clearer picture either with comments or updates to these patches.
> I
> need to look into some of the detail to determine how it aligns.
>
> I may squash these patches together if that is OK?


Yeah no problem

It makes it easier to amend.
>
> Also, are there any RSB changes outstanding to build a suitable QEMU?
>

Oh yes, I still have that build. I'll take a look at it tonight, see if
it's still ok.

>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] covoar: Add symbol set reader and ELF data parser to covoar.

[Cillian O'Donnell]

On Fri, 27 Apr 2018, 04:48 Chris Johns,  wrote:

> On 27/04/2018 08:51, Joel Sherrill wrote:
> >
> >// Create the set of desired symbols.
> >SymbolsToAnalyze = new Coverage::DesiredSymbols();
> > -  SymbolsToAnalyze->load( symbolsFile );
> >
> >
> > I am having trouble seeing what happened to the DesiredSymbols class. Is
> > it no longer needed?


It's still being used as before, the decision has just been split from did
you provided the symbols file or are you using symbol_set.cfg file.
DesiredSymbols is definitely still being used. I'm looking on my phone  so
maybe missing something that would be clearer not on a phone.

Just to update, I didn't get time to look at the rsb build yesterday so
it'll have to be tonight. Sorry for the delay, my new job keeps me very
busy during the week, long commutes too.

Did

we change the class from which SymbolsToAnalyze
> > is derived but provide all the same needed interfaces?
> >
> > I'm having trouble seeing how the new class fits in. Help me.
>
> I am adding support to determine the build top from the executable path(s)
> and
> to verify the build path, arch prefix and BSP match for all executables
> passed
> in and then I will load the symbols from the libraries listed in the
> config file
> directly into the desired symbols class. It looks me like these extra
> classes
> are not needed.
>
> Chris
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/2] rtems-tools/../testing: Add configuration files for coverage analysis.

[Cillian O'Donnell]

Yeah the config files are definitely a bit of a pick-a-mix. I only really
made changes in the .ini and symbolset.cfg. The rest is mostly yours I
guess Joel. You probably have the best idea of what to do with it. I think
Chris wants to squash it together, add his changes and make new patches.

On Thu, 26 Apr 2018, 23:55 Joel Sherrill,  wrote:

> This looks like a mixed bag of stuff. The qemu cfg file could be by itself.
>
> Two files (Jiri's email and details on writing an Explanations.txt) could
> go
> in a (currently non-existent) document on running coverage.
>
> The .css file is a support file for the output.
>
> Not sure where the else fall but these seems like a handful of small
> patches
> rather than one larger patch.
>
> --joel
>
> On Wed, Apr 25, 2018 at 3:33 PM, Cillian O'Donnell 
> wrote:
>
>> Co-author: Krzysztof Miesowicz 
>> Co-author: Vijay Kumar Banerjee 
>> ---
>>  tester/rtems/testing/bsps/leon3_qemu.ini   |  52 ++
>>  tester/rtems/testing/coverage.ini  |  49 +
>>  tester/rtems/testing/coverage/Categories.txt   |  19 ++
>>  tester/rtems/testing/coverage/Explanations.txt |  35 
>>  .../coverage/SPARC-Annul-Slot-Explanation.txt  |  56 ++
>>  tester/rtems/testing/coverage/style.css| 197
>> +
>>  tester/rtems/testing/coverage/symbol_sets.cfg  |   3 +
>>  tester/rtems/testing/qemu.cfg  |  14 +-
>>  8 files changed, 424 insertions(+), 1 deletion(-)
>>  create mode 100644 tester/rtems/testing/bsps/leon3_qemu.ini
>>  create mode 100644 tester/rtems/testing/coverage.ini
>>  create mode 100644 tester/rtems/testing/coverage/Categories.txt
>>  create mode 100644 tester/rtems/testing/coverage/Explanations.txt
>>  create mode 100644
>> tester/rtems/testing/coverage/SPARC-Annul-Slot-Explanation.txt
>>  create mode 100644 tester/rtems/testing/coverage/style.css
>>  create mode 100644 tester/rtems/testing/coverage/symbol_sets.cfg
>>
>> diff --git a/tester/rtems/testing/bsps/leon3_qemu.ini
>> b/tester/rtems/testing/bsps/leon3_qemu.ini
>> new file mode 100644
>> index 000..9888008
>> --- /dev/null
>> +++ b/tester/rtems/testing/bsps/leon3_qemu.ini
>> @@ -0,0 +1,52 @@
>> +#
>> +# RTEMS Tools Project (http://www.rtems.org/)
>> +# Copyright 2010-2014 Chris Johns (chr...@rtems.org)
>> +# All rights reserved.
>> +#
>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> +#
>> +# Redistribution and use in source and binary forms, with or without
>> +# modification, are permitted provided that the following conditions are
>> met:
>> +#
>> +# 1. Redistributions of source code must retain the above copyright
>> notice,
>> +# this list of conditions and the following disclaimer.
>> +#
>> +# 2. Redistributions in binary form must reproduce the above copyright
>> notice,
>> +# this list of conditions and the following disclaimer in the
>> documentation
>> +# and/or other materials provided with the distribution.
>> +#
>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> "AS IS"
>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
>> THE
>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>> PURPOSE
>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
>> BE
>> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> BUSINESS
>> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
>> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
>> THE
>> +# POSSIBILITY OF SUCH DAMAGE.
>> +#
>> +
>> +#
>> +# The Leon 3 QEMU BSP
>> +#
>> +[global]
>> +coverage_supported   = 1
>> +bsp  = leon3_qemu
>> +[leon3_qemu]
>> +bsp   = leon3_qemu
>> +arch  = sparc
>> +tester= %{_rtscripts}/qemu.cfg
>> +bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
>> +
>> +
>> +[coverage]
>> +format   = QEMU
>> +target   = sparc-rtems5
>> +explanations = %{_rtscripts}/coverage/Explanations.txt
>> +coverage_extension   = .cov
>> +gcnos_file   = %{_rtscripts}/coverage/rtems.gcnos
&

Re: [PATCH 1/2] covoar: Add symbol set reader and ELF data parser to covoar.

[Cillian O'Donnell]

On Fri, 27 Apr 2018, 08:32 Chris Johns,  wrote:

> On 27/04/2018 17:21, Cillian O'Donnell wrote:
> > On Fri, 27 Apr 2018, 04:48 Chris Johns,  > <mailto:chr...@rtems.org>> wrote:
> >
> > On 27/04/2018 08:51, Joel Sherrill wrote:
> > >
> > >// Create the set of desired symbols.
> > >SymbolsToAnalyze = new Coverage::DesiredSymbols();
> > > -  SymbolsToAnalyze->load( symbolsFile );
> > >
> > >
> > > I am having trouble seeing what happened to the DesiredSymbols
> class. Is
> > > it no longer needed?
> >
> >
> > It's still being used as before, the decision has just been split from
> did you
> > provided the symbols file or are you using symbol_set.cfg file.
> DesiredSymbols
> > is definitely still being used. I'm looking on my phone  so maybe missing
> > something that would be clearer not on a phone.
>
> I have renamed a few files, for example ..
>
>  tester/rtems/testing/coverage/symbol_sets.cfg ->
> tester/rtems/testing/coverage/score-symbols.ini
>
> and that file now contains:
>
> [symbol-sets]
> sets = score
>
> [score]
> libraries=@BUILD-PREFIX@/c/@BSP@/cpukit/score/libscore.a
>

Fantastic, that solves the build path problem. Thanks.

>
> I have added code to get the build path, BUILD-PREFIX and BSP from the
> executable's path and check each executable is from the same build tree.
>
> I may check these against the RLD's automatically detected values after
> loading
> the libraries.
>
> I have add the code to load the libraries and the required symbols.
>
> This means some of the code to read the sets and then load the libraries
> and
> create a symbol file can be removed.
>

Ah ok, yes I see.

>
> I have not attempted to build to the code and will do this over the
> weekend or
> next week.
>
> > Just to update, I didn't get time to look at the rsb build yesterday so
> it'll
> > have to be tonight. Sorry for the delay, my new job keeps me very busy
> during
> > the week, long commutes too.
>
> No problem, when you can.
>
> Thank you.
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] *** Covoar Outstanding Changes ***

[Cillian O'Donnell]

On 26 April 2018 at 08:50, Chris Johns  wrote:

> On 26/04/2018 16:11, Cillian O'Donnell wrote:
> > On Thu, 26 Apr 2018, 03:27 Chris Johns,  > <mailto:chr...@rtems.org>> wrote:
> >
> >> Also, are there any RSB changes outstanding to build a suitable QEMU?
> >
> > Oh yes, I still have that build. I'll take a look at it tonight, see if
> it's
> > still ok.
> >
>
> Thank you. I can then look at testing those changes as well.
>

Just ran the rsb build there, it finishes with no error messages and
appears to be successful but no tools end up in the prefix location.
Nothing obviously wrong in the log. Have you seen that before? Same thing
with the qemu that's currently in the rsb. Has anyone tried to build qemu
with the rsb recently?

...
installing:
couverture-qemu-e9299f7591c8ecf3389922f4e7672b6bc5deae71-x86_64-linux-gnu-1
-> /home/cpod/development/5
cleaning: gettext-0.18.3.1-x86_64-linux-gnu-1
cleaning: libffi-3.0.13-x86_64-linux-gnu-1
cleaning: pixman-0.32.4-x86_64-linux-gnu-1
cleaning: glib-2.39.3-x86_64-linux-gnu-1
cleaning: dtc-1.4.1-x86_64-linux-gnu-1
cleaning:
couverture-qemu-e9299f7591c8ecf3389922f4e7672b6bc5deae71-x86_64-linux-gnu-1
Build Set: Time 0:06:57.495306


> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/2] *** Covoar Outstanding Changes ***

[Cillian O'Donnell]

On 28 April 2018 at 01:25, Chris Johns  wrote:

>
>
> On 28/4/18 7:41 am, Cillian O'Donnell wrote:
> >
> >
> > On 26 April 2018 at 08:50, Chris Johns  > <mailto:chr...@rtems.org>> wrote:
> >
> > On 26/04/2018 16:11, Cillian O'Donnell wrote:
> > > On Thu, 26 Apr 2018, 03:27 Chris Johns,  chr...@rtems.org>
> > > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> > >
> > >> Also, are there any RSB changes outstanding to build a suitable
> QEMU?
> > >
> > > Oh yes, I still have that build. I'll take a look at it tonight,
> see if it's
> > > still ok.
> > >
> >
> > Thank you. I can then look at testing those changes as well.
> >
> > Just ran the rsb build there, it finishes with no error messages and
> appears to
> > be successful but no tools end up in the prefix location. Nothing
> obviously
> > wrong in the log. Have you seen that before? Same thing with the qemu
> that's
> > currently in the rsb. Has anyone tried to build qemu with the rsb
> recently?
>
> Yes, I happened to build it yesterday on FreeBSD:
>
> $ ../source-builder/sb-set-builder --prefix=/opt/work/rtems/qemu \
> --log=qemu.txt devel/qemu
> $ ls /opt/work/rtems/qemu/bin
> autopoint   qemu-system-i386
> envsubstqemu-system-lm32
> gettext qemu-system-m68k
> gettext.sh  qemu-system-microblaze
> gettextize  qemu-system-microblazeel
> msgattrib   qemu-system-mips
> msgcat  qemu-system-mips64
> msgcmp  qemu-system-mips64el
> msgcomm qemu-system-mipsel
> msgconv qemu-system-moxie
> msgen   qemu-system-or32
> msgexec qemu-system-ppc
> msgfilter   qemu-system-ppc64
> msgfmt  qemu-system-ppcemb
> msggrep qemu-system-s390x
> msginit qemu-system-sh4
> msgmergeqemu-system-sh4eb
> msgunfmtqemu-system-sparc
> msguniq qemu-system-sparc64
> ngettextqemu-system-tricore
> qemu-ga qemu-system-unicore32
> qemu-i386   qemu-system-x86_64
> qemu-sparc  qemu-system-xtensa
> qemu-sparc64qemu-system-xtensaeb
> qemu-system-aarch64 qemu-x86_64
> qemu-system-alpha   recode-sr-latin
> qemu-system-arm xgettext
> qemu-system-cris
>
> Is there a patch I download and test?
>

Hmmm, well if that's working for you then the couverture build should be
fine, they're fairly similar. I'll send the patches in now.

>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/3] source-builder/config: Add couverture-qemu general config & build instructions.

[Cillian O'Donnell]

---
 source-builder/config/couverture-qemu-2-1.cfg | 104 ++
 1 file changed, 104 insertions(+)
 create mode 100644 source-builder/config/couverture-qemu-2-1.cfg

diff --git a/source-builder/config/couverture-qemu-2-1.cfg 
b/source-builder/config/couverture-qemu-2-1.cfg
new file mode 100644
index 000..b0a31bb
--- /dev/null
+++ b/source-builder/config/couverture-qemu-2-1.cfg
@@ -0,0 +1,104 @@
+#
+# This configuration file configure's, make's and install's Couverture-QEMU.
+#
+
+%if %{release} == %{nil}
+  %define release 1
+%endif
+
+#
+# The description.
+#
+Name:  couverture-qemu-%{qemu_version}-%{_host}-%{release}
+Summary:   Couverture-Qemu is a processor simulator with extra trace ability.
+Version:   %{qemu_version}
+Release:   %{release}
+URL:  https://github.com/AdaCore/qemu
+BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
+
+#
+# List of architectures to be built
+#
+%define qemu_archs arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu
+%define qemu_archs %{qemu_archs},ppc-softmmu,sparc-softmmu
+
+#
+# Prepare the source code.
+#
+%prep
+  build_top=$(pwd)
+
+  source_dir_qemu="qemu-%{qemu_version}"
+  %source setup qemu -n qemu-%{qemu_version}
+  %patch setup qemu -p1
+
+  cd ${build_top}
+
+%build
+  build_top=$(pwd)
+
+  %{build_directory}
+
+  mkdir -p ${build_dir}
+  cd ${build_dir}
+
+  %if %{pkgconfig check vdeplug}
+VDE_CONFIG="--enable-vde"
+VDE_CFLAGS="%{pkgconfig cflags vdeplug}"
+VDE_LDFLAGS="%{pkgconfig ldflags vdeplug} %{pkgconfig libs vdeplug}"
+  %endif
+
+  %{host_build_flags}
+
+  if test "%{_build}" != "%{_host}" ; then
+CROSS_PREFIX_OPTION="--cross-prefix=%{_host}-"
+  fi
+
+  SYSROOT=$SB_TMPPREFIX
+
+  #
+  # The --extra-cflags and --extra-ldflags do not work as expected.
+  #
+  # Hack warning: MSYS2 does not seem to convert the path to
+  #   a shell path from Windows so we keep them
+  #   separate and handle it in the pkgconfig tool.
+  #
+  PKG_CONFIG_DEFAULT_PATH=${PKG_CONFIG_PATH} \
+  PKG_CONFIG_PATH=$SYSROOT/lib/pkgconfig \
+  PKG_CONFIG_BUILD_TOP_DIR=$SB_TMPROOT \
+  %{_ld_library_path}=$SYSROOT/lib \
+  LDFLAGS="-Wl,-rpath -Wl,/$SB_PREFIX_CLEAN/lib ${VDE_LDFLAGS}" \
+  CFLAGS="${CFLAGS} ${VDE_CFLAGS}" \
+  ../${source_dir_qemu}/configure \
+--prefix=%{_prefix} \
+${CROSS_PREFIX_OPTION} \
+--make=%{__make} \
+--target-list=%{?with_qemu_archs:%{with_qemu_archs}}\
+  %{!?with_qemu_archs:%{qemu_archs}} \
+${VDE_CONFIG} \
+--disable-smartcard-nss \
+--disable-tools \ 
+--disable-pie \ 
+--disable-vnc \ 
+--disable-sdl \ 
+--disable-gtk \ 
+--disable-opengl \ 
+--disable-netmap \ 
+--disable-werror \
+--disable-virtfs \
+--disable-docs
+
+  %{_ld_library_path}=$SYSROOT/lib \
+  %{__make} %{?_smp_mflags} all
+
+  cd ${build_top}
+
+%install
+  build_top=$(pwd)
+
+  %{__rmdir} $SB_BUILD_ROOT
+
+  cd ${build_dir}
+  %{_ld_library_path}=$SYSROOT/lib \
+  %{__make} DESTDIR=$SB_BUILD_ROOT install
+  cd ${build_top}
-- 
2.7.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 3/3] bare/config/devel: Add couverture-qemu build dependencies.

[Cillian O'Donnell]

---
 bare/config/devel/couverture-qemu.bset | 25 +
 1 file changed, 25 insertions(+)
 create mode 100644 bare/config/devel/couverture-qemu.bset

diff --git a/bare/config/devel/couverture-qemu.bset 
b/bare/config/devel/couverture-qemu.bset
new file mode 100644
index 000..6d08797
--- /dev/null
+++ b/bare/config/devel/couverture-qemu.bset
@@ -0,0 +1,25 @@
+#
+# Build set for Couverture-QEMU
+#
+
+%define release 1
+
+#
+# Name of the package.
+#
+package: couverture-qemu-%{qemu_version}-%{_host}-%{release}
+
+#
+# A magic internal path that would break if changes in the defaults.mc
+# macro file are made.
+#
+%define _internal_autotools_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
+
+devel/autotools-internal
+devel/libiconv-1.14-1
+devel/gettext-0.18.3.1-1
+devel/libffi-3.0.13-1
+devel/pixman-0.32.4-1
+devel/glib-2.39.3-1
+devel/dtc-1.4.1-1
+devel/couverture-qemu-git-1
-- 
2.7.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/3] bare/config/devel: Add couverture-qemu source location and patches needed.

[Cillian O'Donnell]

---
 bare/config/devel/couverture-qemu-git-1.cfg | 32 +
 1 file changed, 32 insertions(+)
 create mode 100644 bare/config/devel/couverture-qemu-git-1.cfg

diff --git a/bare/config/devel/couverture-qemu-git-1.cfg 
b/bare/config/devel/couverture-qemu-git-1.cfg
new file mode 100644
index 000..c832bcc
--- /dev/null
+++ b/bare/config/devel/couverture-qemu-git-1.cfg
@@ -0,0 +1,32 @@
+#
+# Qemu from git
+#
+
+%if %{release} == %{nil}
+ %define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%include %{_configdir}/bare-config.cfg
+
+#
+# Stable version. Qemu is fast moving.
+#
+%define qemu_version e9299f7591c8ecf3389922f4e7672b6bc5deae71
+
+#
+# Set Couverture-Qemu source from github.
+#
+%source set qemu https://github.com/AdaCore/qemu/archive/%{qemu_version}.tar.gz
+
+#
+# Patch to send halt signal to qemu-system-or32 process when RTEMS terminates
+#
+%patch add qemu 
%{rtems_http_git}/rtems-tools/plain/tools/qemu/0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch
+%hash sha256 0001-openrisc-terminate-qemu-process-upon-receiving-a-hal.patch 
88cd5c9e6e2a6bab23bf049a6f4212ff00083b002b73dbe63b2fe9832717f19e
+
+#
+# The Qemu build instructions. We use 2.x.x Release 1.
+#
+%include %{_configdir}/couverture-qemu-2-1.cfg
-- 
2.7.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar: Add symbol set reader and ELF data parser to covoar.

[Cillian O'Donnell]

On 28 April 2018 at 08:08, Chris Johns  wrote:

> From: Cillian O'Donnell 
>
> Add ability to organize symbol sets of libraries in INI file
> and then read them with covoar and load the symbols directly from the
> libraries.
>
> rtems-tools/../testing: Add configuration files for coverage analysis.
>
> A number of covoar options are not required and are defaulted.
>
> Co-author: Krzysztof Miesowicz 
> Co-author: Vijay Kumar Banerjee 
> Cp-author: Chris Johns 
> ---
>  tester/covoar/DesiredSymbols.cc| 144 +-
>  tester/covoar/DesiredSymbols.h |  14 +-
>  tester/covoar/ExecutableInfo.cc|   4 +-
>  tester/covoar/ExecutableInfo.h |   6 +-
>  tester/covoar/ObjdumpProcessor.cc  |   6 +-
>  tester/covoar/app_common.h |   9 +-
>  tester/covoar/covoar.cc| 300
> +
>  tester/covoar/wscript  |   2 +
>  tester/rtems/testing/bsps/leon3-qemu-cov.ini   |  39 +++
>  tester/rtems/testing/bsps/leon3-qemu.ini   |  38 +++
>  tester/rtems/testing/coverage/Categories.txt   |  19 ++
>  tester/rtems/testing/coverage/Explanations.txt |  35 +++
>  .../coverage/SPARC-Annul-Slot-Explanation.txt  |  56 
>  tester/rtems/testing/coverage/score-symbols.ini|  35 +++
>  tester/rtems/testing/coverage/style.css| 197 ++
>  tester/rtems/testing/qemu.cfg  |  11 +-
>  tester/rtems/testing/testing.mc|   8 +
>  17 files changed, 737 insertions(+), 186 deletions(-)
>  create mode 100644 tester/rtems/testing/bsps/leon3-qemu-cov.ini
>  create mode 100644 tester/rtems/testing/bsps/leon3-qemu.ini
>  create mode 100644 tester/rtems/testing/coverage/Categories.txt
>  create mode 100644 tester/rtems/testing/coverage/Explanations.txt
>  create mode 100644 tester/rtems/testing/coverage/
> SPARC-Annul-Slot-Explanation.txt
>  create mode 100644 tester/rtems/testing/coverage/score-symbols.ini
>  create mode 100644 tester/rtems/testing/coverage/style.css
>
> diff --git a/tester/covoar/DesiredSymbols.cc b/tester/covoar/
> DesiredSymbols.cc
> index 00d1984..9957b28 100644
> --- a/tester/covoar/DesiredSymbols.cc
> +++ b/tester/covoar/DesiredSymbols.cc
> @@ -16,6 +16,13 @@
>  #include 
>  #include 
>
> +#include 
> +
> +#include "rld.h"
> +#include 
> +#include "rld-symbols.h"
> +#include "rld-files.h"
> +
>  #include "DesiredSymbols.h"
>  #include "app_common.h"
>  #include "CoverageMap.h"
> @@ -31,75 +38,90 @@ namespace Coverage {
>{
>}
>
> -  void DesiredSymbols::load(
> -const char* const symbolsFile
> +  bool DesiredSymbols::load(
> +const std::string& symbolsSet,
> +const std::string& buildTarget,
> +const std::string& buildBSP,
> +bool   verbose
>)
>{
> -int cStatus;
> -booldone = false;
> -FILE*   sFile;
> -SymbolInformation*  symInfo;
> -int line = 1;
> -std::string symbol;
> -
> -// Ensure that symbols file name is given.
> -if ( !symbolsFile ) {
> -  fprintf(
> -stderr,
> -"ERROR: DesiredSymbols::load - no symbols file specified\n"
> -  );
> -  exit(-1);
> -}
> -
> -// Open symbols file.
> -sFile = fopen( symbolsFile, "r" );
> -if ( !sFile ) {
> -  fprintf(
> -stderr,
> -"ERROR: DesiredSymbols::load - unable to open symbols file %s\n",
> -symbolsFile
> -  );
> -  exit(-1);
> -}
> -
> -// Process symbols file.
> -while ( !done ) {
> -
> -  symInfo = new SymbolInformation;
> -
> -  // Skip blank lines between symbols
> -  do {
> -inputBuffer[0] = '\0';
> -inputBuffer2[0] = '\0';
> -cStatus = fscanf( sFile, "%s %s", inputBuffer, inputBuffer2 );
> -if ( cStatus == EOF ) {
> -  done = true;
> +rld::files::cache cache;
> +bool  r = true;
> +
> +//
> +// Load the INI file looking for a top level:
> +//
> +//  [symbols-sets]
> +//  sets = A, B, C
> +//
> +// For each set read the libraries from the configuration file and
> load.
> +//
> +//  [A]
> +//  libraries = @BUILD-PREFIX@/c/@BSP@/A/libA.a
> +//
> +//  [B]
> +//  libraries = @BUILD-PREFIX@/c/@BSP@/B/libB.a
> +

Re: [PATCH] covoar: Add symbol set reader and ELF data parser to covoar.

[Cillian O'Donnell]

On 28 April 2018 at 17:29, Vijay Kumar Banerjee 
wrote:

> I'm getting the following error after applying the patch:
>

Did you apply it to the current rtems-tools master? It's building fine for
me.

>
> -
> ./waf build install
> Waf: Entering directory `/home/lunatic/development/
> rtems/test/rtems-tools/build'
> Traceback (most recent call last):
>   File "/home/lunatic/development/rtems/test/rtems-tools/.waf-1.9.9-
> 75529a659e4f06cb4254801e52405e0a/waflib/Scripting.py", line 120, in
> waf_entry_point
> run_commands()
>   File "/home/lunatic/development/rtems/test/rtems-tools/.waf-1.9.9-
> 75529a659e4f06cb4254801e52405e0a/waflib/Scripting.py", line 181, in
> run_commands
> ctx=run_command(cmd_name)
>   File "/home/lunatic/development/rtems/test/rtems-tools/.waf-1.9.9-
> 75529a659e4f06cb4254801e52405e0a/waflib/Scripting.py", line 172, in
> run_command
> ctx.execute()
>   File "/home/lunatic/development/rtems/test/rtems-tools/.waf-1.9.9-
> 75529a659e4f06cb4254801e52405e0a/waflib/Scripting.py", line 362, in
> execute
> return execute_method(self)
>   File "/home/lunatic/development/rtems/test/rtems-tools/.waf-1.9.9-
> 75529a659e4f06cb4254801e52405e0a/waflib/Build.py", line 99, in execute
> self.execute_build()
>   File "/home/lunatic/development/rtems/test/rtems-tools/.waf-1.9.9-
> 75529a659e4f06cb4254801e52405e0a/waflib/Build.py", line 102, in
> execute_build
> self.recurse([self.run_dir])
>   File "/home/lunatic/development/rtems/test/rtems-tools/.waf-1.9.9-
> 75529a659e4f06cb4254801e52405e0a/waflib/Context.py", line 129, in recurse
> user_function(self)
>   File "/home/lunatic/development/rtems/test/rtems-tools/wscript", line
> 134, in build
> recurse(ctx)
>   File "/home/lunatic/development/rtems/test/rtems-tools/wscript", line
> 81, in recurse
> ctx.recurse(sd)
>   File "/home/lunatic/development/rtems/test/rtems-tools/.waf-1.9.9-
> 75529a659e4f06cb4254801e52405e0a/waflib/Context.py", line 129, in recurse
> user_function(self)
>   File "/home/lunatic/development/rtems/test/rtems-tools/tester/wscript",
> line 48, in build
> recurse(bld)
>   File "/home/lunatic/development/rtems/test/rtems-tools/tester/wscript",
> line 35, in recurse
> ctx.recurse(sd)
>   File "/home/lunatic/development/rtems/test/rtems-tools/.waf-1.9.9-
> 75529a659e4f06cb4254801e52405e0a/waflib/Context.py", line 129, in recurse
> user_function(self)
>   File 
> "/home/lunatic/development/rtems/test/rtems-tools/tester/covoar/wscript",
> line 115, in build
> use = ['ccovoar'] + modules,
> NameError: global name 'modules' is not defined
>
>
> -- vijay
>
> On 28 April 2018 at 21:54, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 28 April 2018 at 08:08, Chris Johns  wrote:
>>
>>> From: Cillian O'Donnell 
>>>
>>> Add ability to organize symbol sets of libraries in INI file
>>> and then read them with covoar and load the symbols directly from the
>>> libraries.
>>>
>>> rtems-tools/../testing: Add configuration files for coverage analysis.
>>>
>>> A number of covoar options are not required and are defaulted.
>>>
>>> Co-author: Krzysztof Miesowicz 
>>> Co-author: Vijay Kumar Banerjee 
>>> Cp-author: Chris Johns 
>>> ---
>>>  tester/covoar/DesiredSymbols.cc| 144 +-
>>>  tester/covoar/DesiredSymbols.h |  14 +-
>>>  tester/covoar/ExecutableInfo.cc|   4 +-
>>>  tester/covoar/ExecutableInfo.h |   6 +-
>>>  tester/covoar/ObjdumpProcessor.cc  |   6 +-
>>>  tester/covoar/app_common.h |   9 +-
>>>  tester/covoar/covoar.cc| 300
>>> +
>>>  tester/covoar/wscript  |   2 +
>>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini   |  39 +++
>>>  tester/rtems/testing/bsps/leon3-qemu.ini   |  38 +++
>>>  tester/rtems/testing/coverage/Categories.txt   |  19 ++
>>>  tester/rtems/testing/coverage/Explanations.txt |  35 +++
>>>  .../coverage/SPARC-Annul-Slot-Explanation.txt  |  56 
>>>  tester/rtems/testing/coverage/score-symbols.ini|  35 +++
>>>  tester/rtems/testing/coverage/style.css| 197 ++
>>>  tester/rtems/testing/qemu.cfg  |  11 +-
>>>  tester/rtems/testing/

Re: [PATCH] covoar: Add symbol set reader and ELF data parser to covoar.

[Cillian O'Donnell]

On Sat, 28 Apr 2018, 20:39 Vijay Kumar Banerjee, 
wrote:

>
> This is the log file that I'm getting after running the test
>
> I'm getting  a lot of 'invalid' results , am I missing something ?
>

What we had in coverage.py and test.py will need to be updated with Chris'
change to covoar. It's probably best not to run it with rtems-test until
we've revised that. We'll just be testing covoar by itself for the moment.
The focus will probably be on removing covoars dependency on external tools
next.

Chris will we pass in the score ini to -S option now and then the other
options are picked up from there? (Excluding -p and -E).

>
> after this patch along with with the c++ cleanup patch, we have to start
> working on parsing the coverage right?
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar: Add symbol set reader and ELF data parser to covoar.

[Cillian O'Donnell]

On 28 April 2018 at 08:08, Chris Johns  wrote:

> From: Cillian O'Donnell 
>
> Add ability to organize symbol sets of libraries in INI file
> and then read them with covoar and load the symbols directly from the
> libraries.
>
> rtems-tools/../testing: Add configuration files for coverage analysis.
>
> A number of covoar options are not required and are defaulted.
>
> Co-author: Krzysztof Miesowicz 
> Co-author: Vijay Kumar Banerjee 
> Cp-author: Chris Johns 
> ---
>  tester/covoar/DesiredSymbols.cc| 144 +-
>  tester/covoar/DesiredSymbols.h |  14 +-
>  tester/covoar/ExecutableInfo.cc|   4 +-
>  tester/covoar/ExecutableInfo.h |   6 +-
>  tester/covoar/ObjdumpProcessor.cc  |   6 +-
>  tester/covoar/app_common.h |   9 +-
>  tester/covoar/covoar.cc| 300
> +
>  tester/covoar/wscript  |   2 +
>  tester/rtems/testing/bsps/leon3-qemu-cov.ini   |  39 +++
>  tester/rtems/testing/bsps/leon3-qemu.ini   |  38 +++
>  tester/rtems/testing/coverage/Categories.txt   |  19 ++
>  tester/rtems/testing/coverage/Explanations.txt |  35 +++
>  .../coverage/SPARC-Annul-Slot-Explanation.txt  |  56 
>  tester/rtems/testing/coverage/score-symbols.ini|  35 +++
>  tester/rtems/testing/coverage/style.css| 197 ++
>  tester/rtems/testing/qemu.cfg  |  11 +-
>  tester/rtems/testing/testing.mc|   8 +
>  17 files changed, 737 insertions(+), 186 deletions(-)
>  create mode 100644 tester/rtems/testing/bsps/leon3-qemu-cov.ini
>  create mode 100644 tester/rtems/testing/bsps/leon3-qemu.ini
>  create mode 100644 tester/rtems/testing/coverage/Categories.txt
>  create mode 100644 tester/rtems/testing/coverage/Explanations.txt
>  create mode 100644 tester/rtems/testing/coverage/
> SPARC-Annul-Slot-Explanation.txt
>  create mode 100644 tester/rtems/testing/coverage/score-symbols.ini
>  create mode 100644 tester/rtems/testing/coverage/style.css
>
> diff --git a/tester/covoar/DesiredSymbols.cc b/tester/covoar/
> DesiredSymbols.cc
> index 00d1984..9957b28 100644
> --- a/tester/covoar/DesiredSymbols.cc
> +++ b/tester/covoar/DesiredSymbols.cc
> @@ -16,6 +16,13 @@
>  #include 
>  #include 
>
> +#include 
> +
> +#include "rld.h"
> +#include 
> +#include "rld-symbols.h"
> +#include "rld-files.h"
> +
>  #include "DesiredSymbols.h"
>  #include "app_common.h"
>  #include "CoverageMap.h"
> @@ -31,75 +38,90 @@ namespace Coverage {
>{
>}
>
> -  void DesiredSymbols::load(
> -const char* const symbolsFile
> +  bool DesiredSymbols::load(
> +const std::string& symbolsSet,
> +const std::string& buildTarget,
> +const std::string& buildBSP,
> +bool   verbose
>)
>{
> -int cStatus;
> -booldone = false;
> -FILE*   sFile;
> -SymbolInformation*  symInfo;
> -int line = 1;
> -std::string symbol;
> -
> -// Ensure that symbols file name is given.
> -if ( !symbolsFile ) {
> -  fprintf(
> -stderr,
> -"ERROR: DesiredSymbols::load - no symbols file specified\n"
> -  );
> -  exit(-1);
> -}
> -
> -// Open symbols file.
> -sFile = fopen( symbolsFile, "r" );
> -if ( !sFile ) {
> -  fprintf(
> -stderr,
> -"ERROR: DesiredSymbols::load - unable to open symbols file %s\n",
> -symbolsFile
> -  );
> -  exit(-1);
> -}
> -
> -// Process symbols file.
> -while ( !done ) {
> -
> -  symInfo = new SymbolInformation;
> -
> -  // Skip blank lines between symbols
> -  do {
> -inputBuffer[0] = '\0';
> -inputBuffer2[0] = '\0';
> -cStatus = fscanf( sFile, "%s %s", inputBuffer, inputBuffer2 );
> -if ( cStatus == EOF ) {
> -  done = true;
> +rld::files::cache cache;
> +bool  r = true;
> +
> +//
> +// Load the INI file looking for a top level:
> +//
> +//  [symbols-sets]
> +//  sets = A, B, C
> +//
> +// For each set read the libraries from the configuration file and
> load.
> +//
> +//  [A]
> +//  libraries = @BUILD-PREFIX@/c/@BSP@/A/libA.a
> +//
> +//  [B]
> +//  libraries = @BUILD-PREFIX@/c/@BSP@/B/libB.a
> +

Re: [PATCH] covoar: Add symbol set reader and ELF data parser to covoar.

[Cillian O'Donnell]

On Sun, 29 Apr 2018, 23:30 Chris Johns,  wrote:

> On 29/04/2018 20:50, Cillian O'Donnell wrote:
> > On 28 April 2018 at 08:08, Chris Johns  > <mailto:chr...@rtems.org>> wrote:
> > +  for (const std::string set : sets) {
> > +if (verbose)
> > +  std::cerr << " Symbol set: " << set << std::endl;
> > +const rld::config::section& set_section =
> config.get_section(set);
> > +rld::strings libs;
> > +rld::config::parse_items (set_section, "libraries", libs,
> true);
> > +for (std::string lib : libs) {
> > +  lib = rld::find_replace(lib, "@BUILD-TARGET@",
> buildTarget);
> > +  lib = rld::find_replace(lib, "@BSP@", buildBSP);
> >
> >
> > Problem here. It tries to find the find the library but doesn't have the
> top
> > build directory.
>
> Yes, this is correct. I have detected the build path in `main` but I
> decided to
> not use it yet and I have not decided if it gets used at all.
>

Ah ok, you were expecting this.

>
> I have not looked at or worked on the qemu side of things, that is next. I
> am
> not sure how this effects things so at this point in time you need to be
> at the
> top of the build tree to work. This is not a bad thing, I think covoar is
> leaving temporary files about the place.
>

Yes the .cov files could be left lying around in the event of a crash. They
are generated while the tests are run, so before covoar starts and then
need to hang around for covoar's use later on. They probably need to be
handled by the tester.

>
> > -  while ((opt = getopt(argc, argv, "1:L:e:c:g:E:f:s:T:O:p:v:d")) !=
> -1) {
> > +  while ((opt = getopt(argc, argv, "1:L:e:c:g:E:f:s:S:T:O:p:vd"))
> != -1) {
> >
> > Missing semicolon between v and d option.
>
> There is no argument to the -v option. With the ':' the option parsing get
> stuffed up.
>

Ok, my mistake.

>
> >  switch (opt) {
> > -  case '1': singleExecutable  = optarg; break;
> > -  case 'L': dynamicLibrary= optarg; break;
> > -  case 'e': executableExtension   = optarg; break;
> > -  case 'c': coverageFileExtension = optarg; break;
> > -  case 'g': gcnosFileName = optarg; break;
> > -  case 'E': explanations  = optarg; break;
> > -  case 'f': format= optarg; break;
> > -  case 's': symbolsFile   = optarg; break;
> > -  case 'T': target= optarg; break;
> > -  case 'O': outputDirectory   = optarg; break;
> > -  case 'v': Verbose   = true;   break;
>
> See here and also `usage(..)`.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/3] source-builder/config: Add couverture-qemu general config & build instructions.

[Cillian O'Donnell]

On Tue, 1 May 2018, 00:52 Chris Johns,  wrote:

> On 28/04/2018 20:18, Cillian O'Donnell wrote:
> > ---
> >  source-builder/config/couverture-qemu-2-1.cfg | 104
> ++
>
> Why a new file? Could the existing qemu config be used?
>

We were thinking at the time that this would eventually replace the qemu
that's there so it was best if it was self contained. They are identical in
places so yes a lot of overlap.

>
> I would prefer to have as few of the global configs as possible and share
> them
> as much as possible.
>
> >  1 file changed, 104 insertions(+)
> >  create mode 100644 source-builder/config/couverture-qemu-2-1.cfg
> >
> > diff --git a/source-builder/config/couverture-qemu-2-1.cfg
> b/source-builder/config/couverture-qemu-2-1.cfg
> > new file mode 100644
> > index 000..b0a31bb
> > --- /dev/null
> > +++ b/source-builder/config/couverture-qemu-2-1.cfg
> > @@ -0,0 +1,104 @@
> > +#
> > +# This configuration file configure's, make's and install's
> Couverture-QEMU.
> > +#
> > +
> > +%if %{release} == %{nil}
> > +  %define release 1
> > +%endif
> > +
> > +#
> > +# The description.
> > +#
> > +Name:  couverture-qemu-%{qemu_version}-%{_host}-%{release}
> > +Summary:   Couverture-Qemu is a processor simulator with extra trace
> ability.
>
> I do not mind we have just the QEMU name and summary.
>
> > +Version:   %{qemu_version}
> > +Release:   %{release}
> > +URL:https://github.com/AdaCore/qemu
> > +BuildRoot: %{_tmppath}/%{name}-root-%(%{__id_u} -n)
> > +
> > +#
> > +# List of architectures to be built
> > +#
> > +%define qemu_archs arm-softmmu,i386-softmmu,lm32-softmmu,mips-softmmu
> > +%define qemu_archs %{qemu_archs},ppc-softmmu,sparc-softmmu
>
> Why limit the archs?
>

These are the ones I tested that produced same results with rtems tester to
the existing qemu. I think there is also ones that aren't relevant to rtems.

>
> > +
> > +#
> > +# Prepare the source code.
> > +#
> > +%prep
> > +  build_top=$(pwd)
> > +
> > +  source_dir_qemu="qemu-%{qemu_version}"
> > +  %source setup qemu -n qemu-%{qemu_version}
>
> Why remove the -q?
>

>From our discussion last year
> 3. What does the -q option do in the %prep section of the build, this
> option shows up in examples in the docs but there is no description of
> what it does?
>
> %source setup qemu -q -n qemu-%{qemu_version}

It is a spec file compatible option that is not used. You can remove the -q.

>
> > +  %patch setup qemu -p1
> > +
> > +  cd ${build_top}
> > +
> > +%build
> > +  build_top=$(pwd)
> > +
> > +  %{build_directory}
> > +
> > +  mkdir -p ${build_dir}
> > +  cd ${build_dir}
> > +
> > +  %if %{pkgconfig check vdeplug}
> > +VDE_CONFIG="--enable-vde"
> > +VDE_CFLAGS="%{pkgconfig cflags vdeplug}"
> > +VDE_LDFLAGS="%{pkgconfig ldflags vdeplug} %{pkgconfig libs vdeplug}"
> > +  %endif
> > +
> > +  %{host_build_flags}
> > +
> > +  if test "%{_build}" != "%{_host}" ; then
> > +CROSS_PREFIX_OPTION="--cross-prefix=%{_host}-"
> > +  fi
> > +
> > +  SYSROOT=$SB_TMPPREFIX
> > +
> > +  #
> > +  # The --extra-cflags and --extra-ldflags do not work as expected.
> > +  #
> > +  # Hack warning: MSYS2 does not seem to convert the path to
> > +  #   a shell path from Windows so we keep them
> > +  #   separate and handle it in the pkgconfig tool.
> > +  #
> > +  PKG_CONFIG_DEFAULT_PATH=${PKG_CONFIG_PATH} \
> > +  PKG_CONFIG_PATH=$SYSROOT/lib/pkgconfig \
> > +  PKG_CONFIG_BUILD_TOP_DIR=$SB_TMPROOT \
> > +  %{_ld_library_path}=$SYSROOT/lib \
> > +  LDFLAGS="-Wl,-rpath -Wl,/$SB_PREFIX_CLEAN/lib ${VDE_LDFLAGS}" \
> > +  CFLAGS="${CFLAGS} ${VDE_CFLAGS}" \
> > +  ../${source_dir_qemu}/configure \
> > +--prefix=%{_prefix} \
> > +${CROSS_PREFIX_OPTION} \
> > +--make=%{__make} \
> > +--target-list=%{?with_qemu_archs:%{with_qemu_archs}}\
> > +  %{!?with_qemu_archs:%{qemu_archs}} \
> > +${VDE_CONFIG} \
> > +--disable-smartcard-nss \
> > +--disable-tools \
> > +--disable-pie \
> > +--disable-vnc \
> > +--disable-sdl \
> > +--disable-gtk \
> > +--disable-opengl \
> > +--disable-netmap \
> > +--disable-werror \
>
> Some of these lines have white space at the end which seems wrong.
>
> > +--disable-virtfs \
> > +--disable-docs
>
> Does the standard qemu build with these added?
>

Not sure, didn't test that.

>
> Chris
>
> > +
> > +  %{_ld_library_path}=$SYSROOT/lib \
> > +  %{__make} %{?_smp_mflags} all
> > +
> > +  cd ${build_top}
> > +
> > +%install
> > +  build_top=$(pwd)
> > +
> > +  %{__rmdir} $SB_BUILD_ROOT
> > +
> > +  cd ${build_dir}
> > +  %{_ld_library_path}=$SYSROOT/lib \
> > +  %{__make} DESTDIR=$SB_BUILD_ROOT install
> > +  cd ${build_top}
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-tools: coverage covoar GSoC merge

[Cillian O'Donnell]

On Thu, 3 May 2018, 16:23 Vijay Kumar Banerjee, 
wrote:

> Hello,
>
> I want to ask some things about the project to get a clear understanding
> of the objectives/milestones and current status of the project. I also seek
> advice on my Tasks/obectives.
>
> 1. The covoar has been updated to read symbols from the library and the
> next milestone is to remove covoar's dependancy on the external tools,
> which Chris is working on . ( Is that correct? )
>

Looks like it won't be necessary for gsoc, so we won't have to wait for
their removal. Chris might still have some other changes to make though and
then we can pull master and branch off from there.

>
> 2. after it is done , the next step,I think, would be to update the
> coverage.py and test.py with the changes in covoar.
>

Yeah getting all the rtems tester code up to a standard that Chris will be
happy to merge it will be the next step.


> While the Covoar is being updated, shall I be looking into the
> documentations and read the code to gain better understanding? Do you
> suggest me to work on some specific task ?
>

Understanding how covoar is working will be useful. Running covoar with -v
option and reading down through covoar.cc should help you get an overview
of what's going on. You don't need to understand every detail, just get a
general sense of it.

Looks like gcov is going to feature heavily in your project. So reading up
on that and understanding what state the gcov support in covoar is like
should be useful.


> Please suggest resources to gain better understanding of how coverage
> analysis works/supposed to work with the rtems tester. (I can even try
> updating the documentations with some help, this will also help me get
> better understanding ).
>
> Thank you.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-tools: coverage covoar GSoC merge

[Cillian O'Donnell]

On Fri, 4 May 2018, 01:15 Chris Johns,  wrote:

> On 04/05/2018 09:04, Joel Sherrill wrote:
> > On Thu, May 3, 2018 at 1:45 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com
> > <mailto:vijaykumar9...@gmail.com>> wrote:
> > On 3 May 2018 at 22:58, Cillian O'Donnell  > <mailto:cpodonne...@gmail.com>> wrote:
> > On Thu, 3 May 2018, 16:23 Vijay Kumar Banerjee,
> > mailto:vijaykumar9...@gmail.com>>
> wrote:
> >
> > Hello,
> >
> > I want to ask some things about the project to get a clear
> > understanding of the objectives/milestones and current
> status of the
> > project. I also seek advice on my Tasks/obectives.
> >
> > 1. The covoar has been updated to read symbols from the
> library and
> > the next milestone is to remove covoar's dependancy on the
> external
> > tools, which Chris is working on . ( Is that correct? )
> >
> >
> > Looks like it won't be necessary for gsoc, so we won't have to
> wait for
> > their removal. Chris might still have some other changes to make
> though
> > and then we can pull master and branch off from there.
> >
> > Understood.
> >
> > If it is working as is, you are OK to work on GSoC objectives. Emphasis
> on the
> > "working" part.
> > If something is broken right now, we want to fix it. :)
>
> Agreed.
>

No covoar is working fine now.

>
> > We also want to make sure all of the previous work is merged into the
> master.
> > There may be
> > clean up left for this. Cillian is the best person to answer this one.
>
> Has patches for this been posted? If they have I may have dropped the ball
> by
> not handling them.
>

Everything covoar related has been posted. Suppose the next thing is fix up
the rtems tester stuff and post those patches for comments. I'll try and do
that over the weekend.


> > Chris has identified things to improve covoar which are not all required
> to be
> > done now.
>
> Yes. I am working on removing addr2line as the first step.
>
> > 2. after it is done , the next step,I think, would be to
> update the
> > coverage.py and test.py with the changes in covoar.
> >
> >
> > Yeah getting all the rtems tester code up to a standard that
> Chris will
> > be happy to merge it will be the next step.
> >
> > So basically we wait for Chris to make the changes to covoar, needed
> for us
> > to start working on coverage code to make it running and up to the
> standards.
> >
> > Chris can answer this. But if it works and produces coverage reports, it
> is ready.
> > If it is broken, report it.
>
> This is correct. The tools currently is host specific and my work is to
> make it
> native and contained so it is portable.
>
> > All clean up and removal of external tools should not impact your
> project if the
> > code is working now. :)
>
> I agree.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: rtems-tools: coverage covoar GSoC merge

[Cillian O'Donnell]

On Fri, 4 May 2018, 00:04 Joel Sherrill,  wrote:

>
>
> On Thu, May 3, 2018 at 1:45 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>> On 3 May 2018 at 22:58, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Thu, 3 May 2018, 16:23 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> I want to ask some things about the project to get a clear
>>>> understanding of the objectives/milestones and current status of the
>>>> project. I also seek advice on my Tasks/obectives.
>>>>
>>>> 1. The covoar has been updated to read symbols from the library and the
>>>> next milestone is to remove covoar's dependancy on the external tools,
>>>> which Chris is working on . ( Is that correct? )
>>>>
>>>
>>> Looks like it won't be necessary for gsoc, so we won't have to wait for
>>> their removal. Chris might still have some other changes to make though and
>>> then we can pull master and branch off from there.
>>>
>> Understood.
>>
>
> If it is working as is, you are OK to work on GSoC objectives. Emphasis on
> the "working" part.
> If something is broken right now, we want to fix it. :)
>
> We also want to make sure all of the previous work is merged into the
> master. There may be
> clean up left for this. Cillian is the best person to answer this one.
>
> Chris has identified things to improve covoar which are not all required
> to be done now.
>
> FWIW some history which might help get some perspective.
>
> covoar was functional about a decade ago and driven by shell scripts that
> are still
> in the rtems-testing repository.  That is executable evidence of the work
> flow. I have some
> odd figures and presentations from about the same time frame. That means
> it predates
> the RSB and rtems-tools. Consequently, it predates using Python and C++ on
> the host
> side for RTEMS tools. The shell scripts driving the process and invoking
> covoar should
> now be all in Python. covoar itself needs some clean up to match current
> C++ practices.
>
> The use of external tools was actually recommended by a binutils
> maintainer at the
> time because the output of the tools is stable. That let us focus on the
> algorithms
> to analyse the coverage. Now we can replace the use of those where
> possible. The
> RTEMS Project did not use the ELF or DWARF libraries back then.
>
> My shell scripts only did a few subsets of code to run reports on. One of
> the big
> changes in the move to Python was a move to reporting on a larger number of
> small sets. For example, report coverage on score, rtems, dosfs, etc.
> rather than
> just "core" or "all".
>
> I think this is the third GSoC project to work on these tools. That
> doesn't count
> at least two students working on RTEMS tests to improve the actual
> coverage.
>
> Hopefully Cillian's work last summer got us over the hurdle of being able
> to generate
> the reports using rtems-tester. Pushing to get all that merged is an
> important and
> critical precondition for this summer. All outstanding work should be in
> the
> RTEMS.org repository.
>
> And all your work should land there as well as soon as it is ready. :)
>
>
>
>>
>>>> 2. after it is done , the next step,I think, would be to update the
>>>> coverage.py and test.py with the changes in covoar.
>>>>
>>>
>>> Yeah getting all the rtems tester code up to a standard that Chris will
>>> be happy to merge it will be the next step.
>>>
>> So basically we wait for Chris to make the changes to covoar, needed for
>> us to start working on coverage code to make it running and up to the
>> standards.
>>
>
> Chris can answer this. But if it works and produces coverage reports, it
> is ready.
> If it is broken, report it.
>
> All clean up and removal of external tools should not impact your project
> if the
> code is working now. :)
>
>
>>>
>>>> While the Covoar is being updated, shall I be looking into the
>>>> documentations and read the code to gain better understanding? Do you
>>>> suggest me to work on some specific task ?
>>>>
>>>
>>> Understanding how covoar is working will be useful. Running covoar with
>>> -v option and reading down through covoar.cc should help you get an
>>> overview of what's going on. You don't need to understand every detail,
>>>

Re: rtems-tools: coverage covoar GSoC merge

[Cillian O'Donnell]

On Fri, 4 May 2018, 07:51 Vijay Kumar Banerjee, 
wrote:

>
>
> On Fri, 4 May 2018, 12:17 Cillian O'Donnell, 
> wrote:
>
>>
>>
>> On Fri, 4 May 2018, 00:04 Joel Sherrill,  wrote:
>>
>>>
>>>
>>> On Thu, May 3, 2018 at 1:45 PM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>>
>>>> On 3 May 2018 at 22:58, Cillian O'Donnell 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, 3 May 2018, 16:23 Vijay Kumar Banerjee, <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I want to ask some things about the project to get a clear
>>>>>> understanding of the objectives/milestones and current status of the
>>>>>> project. I also seek advice on my Tasks/obectives.
>>>>>>
>>>>>> 1. The covoar has been updated to read symbols from the library and
>>>>>> the next milestone is to remove covoar's dependancy on the external 
>>>>>> tools,
>>>>>> which Chris is working on . ( Is that correct? )
>>>>>>
>>>>>
>>>>> Looks like it won't be necessary for gsoc, so we won't have to wait
>>>>> for their removal. Chris might still have some other changes to make 
>>>>> though
>>>>> and then we can pull master and branch off from there.
>>>>>
>>>> Understood.
>>>>
>>>
>>> If it is working as is, you are OK to work on GSoC objectives. Emphasis
>>> on the "working" part.
>>> If something is broken right now, we want to fix it. :)
>>>
>>> We also want to make sure all of the previous work is merged into the
>>> master. There may be
>>> clean up left for this. Cillian is the best person to answer this one.
>>>
>>> Chris has identified things to improve covoar which are not all required
>>> to be done now.
>>>
>>> FWIW some history which might help get some perspective.
>>>
>>> covoar was functional about a decade ago and driven by shell scripts
>>> that are still
>>> in the rtems-testing repository.  That is executable evidence of the
>>> work flow. I have some
>>> odd figures and presentations from about the same time frame. That means
>>> it predates
>>> the RSB and rtems-tools. Consequently, it predates using Python and C++
>>> on the host
>>> side for RTEMS tools. The shell scripts driving the process and invoking
>>> covoar should
>>> now be all in Python. covoar itself needs some clean up to match current
>>> C++ practices.
>>>
>>> The use of external tools was actually recommended by a binutils
>>> maintainer at the
>>> time because the output of the tools is stable. That let us focus on the
>>> algorithms
>>> to analyse the coverage. Now we can replace the use of those where
>>> possible. The
>>> RTEMS Project did not use the ELF or DWARF libraries back then.
>>>
>>> My shell scripts only did a few subsets of code to run reports on. One
>>> of the big
>>> changes in the move to Python was a move to reporting on a larger number
>>> of
>>> small sets. For example, report coverage on score, rtems, dosfs, etc.
>>> rather than
>>> just "core" or "all".
>>>
>>> I think this is the third GSoC project to work on these tools. That
>>> doesn't count
>>> at least two students working on RTEMS tests to improve the actual
>>> coverage.
>>>
>>> Hopefully Cillian's work last summer got us over the hurdle of being
>>> able to generate
>>> the reports using rtems-tester. Pushing to get all that merged is an
>>> important and
>>> critical precondition for this summer. All outstanding work should be in
>>> the
>>> RTEMS.org repository.
>>>
>>> And all your work should land there as well as soon as it is ready. :)
>>>
>>>
>>>
>>>>
>>>>>> 2. after it is done , the next step,I think, would be to update the
>>>>>> coverage.py and test.py with the changes in covoar.
>>>>>>
>>>>>
>>>>> Yeah getting all the rtems tester code up to a standard that Chris
>>>>> will be happy to merge it will be the nex

Re: [PATCH] Add DWARF support to rtemstoolkit and use it in covoar

[Cillian O'Donnell]

Hi Chris,

Getting some build errors here. It complains about dwarf.h and libdwarf.h
so theres 2 packages that I can get them from but both end up producing
some problems. 'Elf' has a previous declaration in one and missing typedef
for the other. Is there a particular version of these libraries that you
are using?

sudo apt-get install libdwarf-freebsd-dev

Theres a typedef error for Dwarf_Handler and Dwarf_Sig8

cpod@cpod ~/development/rtems/test/rtems-tools $ ./waf
Waf: Entering directory
`/home/cpod/development/rtems/test/rtems-tools/build'
[188/229] Compiling tester/covoar/app_common.cc
[189/229] Compiling tester/covoar/CoverageFactory.cc
[193/229] Compiling tester/covoar/CoverageReaderBase.cc
[194/229] Compiling tester/covoar/CoverageReaderQEMU.cc
In file included from ../rtemstoolkit/rld-dwarf.h:29:0,
 from ../tester/covoar/ExecutableInfo.h:14,
 from ../tester/covoar/CoverageReaderBase.h:10,
 from ../tester/covoar/CoverageFactory.h:12,
 from ../tester/covoar/CoverageFactory.cc:13:
../rtemstoolkit/rld-dwarf-types.h:39:15: error: ‘Dwarf_Handler’ in
namespace ‘::’ does not name a type
 typedef ::Dwarf_Handler  dwarf_handler;
   ^
../rtemstoolkit/rld-dwarf-types.h:50:15: error: ‘Dwarf_Sig8’ in namespace
‘::’ does not name a type
 typedef ::Dwarf_Sig8 dwarf_sig8;
   ^

In file included from ../rtemstoolkit/rld-dwarf.h:29:0,
 from ../tester/covoar/ExecutableInfo.h:14,
 from ../tester/covoar/CoverageReaderBase.h:10,
 from ../tester/covoar/CoverageReaderBase.cc:8:
../rtemstoolkit/rld-dwarf-types.h:39:15: error: ‘Dwarf_Handler’ in
namespace ‘::’ does not name a type
 typedef ::Dwarf_Handler  dwarf_handler;
   ^
../rtemstoolkit/rld-dwarf-types.h:50:15: error: ‘Dwarf_Sig8’ in namespace
‘::’ does not name a type
 typedef ::Dwarf_Sig8 dwarf_sig8;
   ^

In file included from ../rtemstoolkit/rld-dwarf.h:29:0,
 from ../tester/covoar/ExecutableInfo.h:14,
 from ../tester/covoar/DesiredSymbols.h:17,
 from ../tester/covoar/app_common.h:11,
 from ../tester/covoar/app_common.cc:40:
../rtemstoolkit/rld-dwarf-types.h:39:15: error: ‘Dwarf_Handler’ in
namespace ‘::’ does not name a type
 typedef ::Dwarf_Handler  dwarf_handler;
   ^
../rtemstoolkit/rld-dwarf-types.h:50:15: error: ‘Dwarf_Sig8’ in namespace
‘::’ does not name a type
 typedef ::Dwarf_Sig8 dwarf_sig8;
   ^

In file included from ../rtemstoolkit/rld-dwarf.h:29:0,
 from ../tester/covoar/ExecutableInfo.h:14,
 from ../tester/covoar/DesiredSymbols.h:17,
 from ../tester/covoar/app_common.h:11,
 from ../tester/covoar/CoverageReaderQEMU.cc:14:
../rtemstoolkit/rld-dwarf-types.h:39:15: error: ‘Dwarf_Handler’ in
namespace ‘::’ does not name a type
 typedef ::Dwarf_Handler  dwarf_handler;
   ^
../rtemstoolkit/rld-dwarf-types.h:50:15: error: ‘Dwarf_Sig8’ in namespace
‘::’ does not name a type
 typedef ::Dwarf_Sig8 dwarf_sig8;
   ^

Waf: Leaving directory `/home/cpod/development/rtems/test/rtems-tools/build'
Build failed
 -> task in 'ccovoar' failed with exit status 1 (run with -v to display
more information)
 -> task in 'ccovoar' failed with exit status 1 (run with -v to display
more information)
 -> task in 'ccovoar' failed with exit status 1 (run with -v to display
more information)
 -> task in 'ccovoar' failed with exit status 1 (run with -v to display
more information)
--


If I chose

sudo apt-get install libdwarf-dev theres a conflict with 'Elf' having a
previous declaration.

Waf: Entering directory
`/home/cpod/development/rtems/test/rtems-tools/build'
[138/229] Linking build/rtemstoolkit/libdwarf.a
[177/229] Linking build/linkers/rtems-ld
[179/229] Linking build/linkers/rtems-ra
[181/229] Linking build/linkers/rtems-tld
[183/229] Linking build/linkers/rtems-syms
[189/229] Linking build/linkers/rtems-rap
[190/229] Linking build/linkers/rtems-exeinfo
[191/229] Compiling tester/covoar/app_common.cc
[192/229] Compiling tester/covoar/CoverageFactory.cc
[193/229] Compiling tester/covoar/CoverageReaderBase.cc
[194/229] Compiling tester/covoar/CoverageReaderQEMU.cc
In file included from ../rtemstoolkit/rld-dwarf-types.h:29:0,
 from ../rtemstoolkit/rld-dwarf.h:29,
 from ../tester/covoar/ExecutableInfo.h:14,
 from ../tester/covoar/DesiredSymbols.h:17,
 from ../tester/covoar/app_common.h:11,
 from ../tester/covoar/app_common.cc:40:
/usr/include/libdwarf.h:66:8: error: using typedef-name ‘Elf’ after ‘struct’
 struct Elf;
^
In file included from ../rtemstoolkit/elftoolchain/libelf/gelf.h:32:0,
 fr

Re: [PATCH 2/4] covoar: Use DWARF to map addresses to source files and lines.

[Cillian O'Donnell]

On 5 May 2018 at 21:12, Chris Johns  wrote:

>
>
> > On 6 May 2018, at 2:44 am, Joel Sherrill  wrote:
> >
> > Looks similar to Cillian's failure. Chris will have to show me where
> libdwarf comes from. It needs to be supplied with RTEMS tools for
> consistency.
>
> You need to apply the patches against master. I added libdwarf to master
> the other day.
>

That is applied to current master. I can see that libdwarf patch in the log
but it still has that problem.

>
> Host packages are not used.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: [PATCH 2/4] covoar: Use DWARF to map addresses to source files and lines.

[Cillian O'Donnell]

Yeah I'm seeing the same as Joel, at least were further then we were :).

I've been mostly working on the rtems-tester support, so just to give an
update. I spent all day Saturday and today on it. It's taking longer than
expected, re-orienting myself and deciding what is needed and not needed
now with the changes in covoar. The problems are not difficult, it's just
taking some time re-organizing everything. My time is limited during the
week, so it'll probably be next weekend before I can finish it off. Vijay
if you have time during the week I could push what I have and you could
take a stab at some of them and then I could it finish off next weekend if
you haven't already.

On 7 May 2018 at 15:40, Joel Sherrill  wrote:

>
>
> On Mon, May 7, 2018 at 6:01 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> I have added the path to libdwarf here
>>
>
> That worked for me to build but not to link.
>
> I'm not sure why this rld symbol turned up missing on Centos 7.
>
> 
>
> $ ./waf -v
> Waf: Entering directory `/home/joel/rtems-work/rtems-tools/build'
> [228/229] Linking build/tester/covoar/trace-converter
> 09:38:25 runner ['/usr/bin/g++', 'tester/covoar/TraceConverter.cc.2.o',
> 'tester/covoar/TraceList.cc.2.o', 'tester/covoar/TraceReaderBase.cc.2.o',
> 'tester/covoar/TraceReaderLogQEMU.cc.2.o', 
> 'tester/covoar/TraceWriterBase.cc.2.o',
> 'tester/covoar/TraceWriterQEMU.cc.2.o', '-o/home/joel/rtems-work/
> rtems-tools/build/tester/covoar/trace-converter', '-Wl,-Bstatic',
> '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', '-lrld', '-ldwarf',
> '-lelf', '-liberty', '-Wl,-Bdynamic']
> [229/229] Linking build/tester/covoar/covoar
> 09:38:25 runner ['/usr/bin/g++', 'tester/covoar/covoar.cc.3.o',
> '-o/home/joel/rtems-work/rtems-tools/build/tester/covoar/covoar',
> '-Wl,-Bstatic', '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', '-lrld',
> '-ldwarf', '-lelf', '-liberty', '-Wl,-Bdynamic']
> tester/covoar/libccovoar.a(DesiredSymbols.cc.1.o): In function
> `Coverage::DesiredSymbols::determineSourceLines(Coverage::CoverageRanges*,
> Coverage::ExecutableInfo*)':
> /home/joel/rtems-work/rtems-tools/build/../tester/covoar/DesiredSymbols.cc:413:
> undefined reference to `rld::path::__xpg_basename(std::string const&)'
> /home/joel/rtems-work/rtems-tools/build/../tester/covoar/DesiredSymbols.cc:415:
> undefined reference to `rld::path::__xpg_basename(std::string const&)'
> collect2: error: ld returned 1 exit status
>
> tester/covoar/libccovoar.a(DesiredSymbols.cc.1.o): In function
> `Coverage::DesiredSymbols::determineSourceLines(Coverage::CoverageRanges*,
> Coverage::ExecutableInfo*)':
> /home/joel/rtems-work/rtems-tools/build/../tester/covoar/DesiredSymbols.cc:413:
> undefined reference to `rld::path::__xpg_basename(std::string const&)'
> /home/joel/rtems-work/rtems-tools/build/../tester/covoar/DesiredSymbols.cc:415:
> undefined reference to `rld::path::__xpg_basename(std::string const&)'
> collect2: error: ld returned 1 exit status
>
> Waf: Leaving directory `/home/joel/rtems-work/rtems-tools/build'
> Build failed
>  -> task in 'trace-converter' failed with exit status 1:
> {task 34721616: cxxprogram TraceConverter.cc.2.o,TraceList.cc.2.o,
> TraceReaderBase.cc.2.o,TraceReaderLogQEMU.cc.2.o,TraceWriterBase.cc.2.o,TraceWriterQEMU.cc.2.o
> -> trace-converter}
> ['/usr/bin/g++', 'tester/covoar/TraceConverter.cc.2.o',
> 'tester/covoar/TraceList.cc.2.o', 'tester/covoar/TraceReaderBase.cc.2.o',
> 'tester/covoar/TraceReaderLogQEMU.cc.2.o', 
> 'tester/covoar/TraceWriterBase.cc.2.o',
> 'tester/covoar/TraceWriterQEMU.cc.2.o', '-o/home/joel/rtems-work/
> rtems-tools/build/tester/covoar/trace-converter', '-Wl,-Bstatic',
> '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', '-lrld', '-ldwarf',
> '-lelf', '-liberty', '-Wl,-Bdynamic']
>  -> task in 'covoar' failed with exit status 1:
> {task 34820256: cxxprogram covoar.cc.3.o -> covoar}
> ['/usr/bin/g++', 'tester/covoar/covoar.cc.3.o', '-o/home/joel/rtems-work/
> rtems-tools/build/tester/covoar/covoar', '-Wl,-Bstatic',
> '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', '-lrld', '-ldwarf',
> '-lelf', '-liberty', '-Wl,-Bdynamic']
> 
>
>
>>
>> ---
>>
>> diff --git a/tester/covoar/wscript b/tester/covoar/wscript
>> index 55d5ec9..dd4ad83 100644
>> --- a/tester/covoar/wscript
>> +++ b/tester/covoar/wscript
>> @@ -63,6 +63,7 @@ def build(bld):
>>  rtl_includes = [rtemstoolkit,
>>  rtemstoolkit + '/elftoolchain/libelf',
>>  rtemstoolkit + '/elftoolchain/common',
>> +rtemstoolkit + '/elftoolchain/libdwarf',
>>  rtemstoolkit + '/libiberty']
>>  if bld.env.DEST_OS == 'win32':
>>  rtl_includes += [rtemstoolkit + '/win32']
>>
>>
>>
>> -- vijay
>>
>> On 7 May 2018 at 13:30, Vijay Kumar Banerjee 
>> wrote:
>>
>>>
>>> On 6 May 2018 at 13:29, Chris Johns  wrote:
>>>
 On 6/5/18 5:28 pm, 

Re: Fwd: [PATCH 2/4] covoar: Use DWARF to map addresses to source files and lines.

[Cillian O'Donnell]

w-p  00:00 0
7ffc5053b000-7ffc5055d000 rw-p  00:00 0
[stack]
7ffc505d5000-7ffc505d7000 r--p  00:00 0
[vvar]
7ffc505d7000-7ffc505d9000 r-xp  00:00 0
[vdso]
ff60-ff601000 r-xp  00:00 0
[vsyscall]
Aborted


> Ultimate solution is probably simple. We just need to hear from Chris.
>
> --joel
>
>
> On Mon, May 7, 2018 at 12:42 PM, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, May 7, 2018 at 12:36 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>> On Mon, 7 May 2018, 22:57 Cillian O'Donnell, 
>>> wrote:
>>>
>>>> Yeah I'm seeing the same as Joel, at least were further then we were :).
>>>>
>>>> I've been mostly working on the rtems-tester support, so just to give
>>>> an update. I spent all day Saturday and today on it. It's taking longer
>>>> than expected, re-orienting myself and deciding what is needed and not
>>>> needed now with the changes in covoar. The problems are not difficult, it's
>>>> just taking some time re-organizing everything. My time is limited during
>>>> the week, so it'll probably be next weekend before I can finish it off.
>>>> Vijay if you have time during the week I could push what I have and you
>>>> could take a stab at some of them and then I could it finish off next
>>>> weekend if you haven't already.
>>>>
>>> please send them, I can look into them for sure.
>>>
>>
>> Keep plugging away.
>>
>> I think there is something wrong in rld related to basename. My first
>> thought was that the undefined symbol was because we didn't include the
>> library. Now I think it is because something got misconfigured on
>> Centos/Fedora/etc. Looking into this.
>>
>>
>>>
>>>> On 7 May 2018 at 15:40, Joel Sherrill  wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, May 7, 2018 at 6:01 AM, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> I have added the path to libdwarf here
>>>>>>
>>>>>
>>>>> That worked for me to build but not to link.
>>>>>
>>>>> I'm not sure why this rld symbol turned up missing on Centos 7.
>>>>>
>>>>> 
>>>>>
>>>>> $ ./waf -v
>>>>> Waf: Entering directory `/home/joel/rtems-work/rtems-tools/build'
>>>>> [228/229] Linking build/tester/covoar/trace-converter
>>>>> 09:38:25 runner ['/usr/bin/g++', 'tester/covoar/TraceConverter.cc.2.o',
>>>>> 'tester/covoar/TraceList.cc.2.o', 'tester/covoar/TraceReaderBase.cc.2.o',
>>>>> 'tester/covoar/TraceReaderLogQEMU.cc.2.o',
>>>>> 'tester/covoar/TraceWriterBase.cc.2.o', 
>>>>> 'tester/covoar/TraceWriterQEMU.cc.2.o',
>>>>> '-o/home/joel/rtems-work/rtems-tools/build/tester/covoar/trace-converter',
>>>>> '-Wl,-Bstatic', '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', '-lrld',
>>>>> '-ldwarf', '-lelf', '-liberty', '-Wl,-Bdynamic']
>>>>> [229/229] Linking build/tester/covoar/covoar
>>>>> 09:38:25 runner ['/usr/bin/g++', 'tester/covoar/covoar.cc.3.o',
>>>>> '-o/home/joel/rtems-work/rtems-tools/build/tester/covoar/covoar',
>>>>> '-Wl,-Bstatic', '-Ltester/covoar', '-Lrtemstoolkit', '-lccovoar', '-lrld',
>>>>> '-ldwarf', '-lelf', '-liberty', '-Wl,-Bdynamic']
>>>>> tester/covoar/libccovoar.a(DesiredSymbols.cc.1.o): In function
>>>>> `Coverage::DesiredSymbols::determineSourceLines(Coverage::CoverageRanges*,
>>>>> Coverage::ExecutableInfo*)':
>>>>> /home/joel/rtems-work/rtems-tools/build/../tester/covoar/DesiredSymbols.cc:413:
>>>>> undefined reference to `rld::path::__xpg_basename(std::string const&)'
>>>>> /home/joel/rtems-work/rtems-tools/build/../tester/covoar/DesiredSymbols.cc:415:
>>>>> undefined reference to `rld::path::__xpg_basename(std::string const&)'
>>>>> collect2: error: ld returned 1 exit status
>>>>>
>>>>> tester/co

Re: Fwd: [PATCH 2/4] covoar: Use DWARF to map addresses to source files and lines.

[Cillian O'Donnell]

Here's the branch with work in progress for the tester. Have a look when
you can Vijay.

https://github.com/cillianodonnell/rtems-tools/tree/tester-support

On 7 May 2018 at 19:59, Cillian O'Donnell  wrote:

>
>
> On 7 May 2018 at 18:56, Joel Sherrill  wrote:
>
>> Hi
>>
>> I have attached a workaround. It seems that libgen.h has this:
>>
>> 
>> /* Return final component of PATH.
>>
>>This is the weird XPG version of this function.  It sometimes will
>>modify its argument.  Therefore we normally use the GNU version (in
>>) and only if this header is included make the XPG
>>version available under the real name.  */
>> extern char *__xpg_basename (char *__path) __THROW;
>> #define basename__xpg_basename
>> 
>>
>> Chris has used basename as a method name and even though that should
>> be perfectly acceptable, the macro above gets expanded, the name
>> gets changed (in some places) to rld::path::__xpg_basename()
>>
>>   r.lowSourceLine = rld::path::basename (location);
>>
>> IMO the fix is to add dirname to rld-files, use rld basename and dirname
>> exclusively, and avoid libgen.h at all costs.
>>
>> I didn't do that much work. I got lucky in a couple of files by removing
>> the
>> include of libgen.h since it wasn't needed but I had to leave it in one
>> place.
>>
>> $ grep dirname *.cc
>> GcovData.cc:dirname( path );
>>
>> Hopefully this lets you all proceed with Chris' patches and my slight hack
>> in place.
>>
>
> Thanks Joel! The good news is that's building now with only a couple of
> warnings.
>
> The bad news is..
>
> cpod@cpod ~/development/rtems/leon3 $ covoar -S
> /home/cpod/development/rtems/test/rtems-tools/tester/rtems/
> testing/coverage/score-symbols.ini -O /home/cpod/coverage_test/test/score
> -E/home/cpod/development/rtems/test/rtems-tools/tester/
> rtems/testing/coverage/Explanations.txt -p RTEMS-5 -v
> sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
> *** Error in `covoar': free(): invalid next size (fast):
> 0x01000360 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fcd0b3477e5]
> /lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7fcd0b35037a]
> /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fcd0b35453c]
> covoar[0x43fcee]
> covoar[0x42bc4a]
> covoar[0x42d205]
> covoar[0x40dec5]
> covoar[0x4054b6]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fcd0b2f0830]
> covoar[0x4073e9]
> === Memory map: 
> 0040-004a8000 r-xp  08:07 3276534
> /home/cpod/development/rtems/test/rtems-tools/build/tester/covoar/covoar
> 006a7000-006a8000 r--p 000a7000 08:07 3276534
> /home/cpod/development/rtems/test/rtems-tools/build/tester/covoar/covoar
> 006a8000-006a9000 rw-p 000a8000 08:07 3276534
> /home/cpod/development/rtems/test/rtems-tools/build/tester/covoar/covoar
> 006a9000-006aa000 rw-p  00:00 0
> 00c6a000-01022000 rw-p  00:00 0
> [heap]
> 7fcd0400-7fcd04021000 rw-p  00:00 0
> 7fcd04021000-7fcd0800 ---p  00:00 0
> 7fcd0a9ae000-7fcd0ac36000 rw-p  00:00 0
> 7fcd0ac36000-7fcd0afc7000 r--p  08:07 2759194
> /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/
> testsuites/samples/hello/hello.exe
> 7fcd0afc7000-7fcd0b0cf000 r-xp  08:07 1838070
> /lib/x86_64-linux-gnu/libm-2.23.so
> 7fcd0b0cf000-7fcd0b2ce000 ---p 00108000 08:07 1838070
> /lib/x86_64-linux-gnu/libm-2.23.so
> 7fcd0b2ce000-7fcd0b2cf000 r--p 00107000 08:07 1838070
> /lib/x86_64-linux-gnu/libm-2.23.so
> 7fcd0b2cf000-7fcd0b2d rw-p 00108000 08:07 1838070
> /lib/x86_64-linux-gnu/libm-2.23.so
> 7fcd0b2d-7fcd0b49 r-xp  08:07 1842682
> /lib/x86_64-linux-gnu/libc-2.23.so
> 7fcd0b49-7fcd0b69 ---p 001c 08:07 1842682
> /lib/x86_64-linux-gnu/libc-2.23.so
> 7fcd0b69-7fcd0b694000 r--p 001c 08:07 1842682
> /lib/x86_64-linux-gnu/libc-2.23.so
> 7fcd0b694000-7fcd0b696000 rw-p 001c4000 08:07 1842682
> /lib/x86_64-linux-gnu/libc-2.23.so
> 7fcd0b696000-7fcd0b69a000 rw-p  00:00 0
> 7fcd0b69a000-7fcd0b6b r-xp  08:07 1836727
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fcd0b6b-7fcd0b8af000 ---p 00016000 08:07 1836727
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fcd0b8af000-7fcd0b8b rw-p 00015000 08:07 1836727
> /lib/x86_64-linux-gnu/libgcc_s.so.1
> 7fcd0b8b-7fcd0ba22000 r-xp  08:07 1049309
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21
> 7fcd0ba22000-7fcd0bc22000

Re: Fwd: [PATCH 2/4] covoar: Use DWARF to map addresses to source files and lines.

[Cillian O'Donnell]

Heres the gdb backtrace. rld-dwarf.cpp rld-path showing up near the bottom.
I don't have valgrind, I'll get it now and see what I find there.

(gdb) bt
#0  0x774aa428 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x774ac02a in __GI_abort () at abort.c:89
#2  0x774ec7ea in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x77605ed8 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/posix/libc_fatal.c:175
#3  0x774f537a in malloc_printerr (ar_ptr=,
ptr=, str=0x77605f50 "free(): invalid next size
(fast)",
action=3) at malloc.c:5006
#4  _int_free (av=, p=, have_lock=0) at
malloc.c:3867
#5  0x774f953c in __GI___libc_free (mem=) at
malloc.c:2968
#6  0x0043fcee in
__gnu_cxx::new_allocator, std::allocator > >::deallocate
(this=0x7fffc730,
__p=) at /usr/include/c++/5/ext/new_allocator.h:110
#7  std::allocator_traits, std::allocator > > >::deallocate (__a=...,
__n=, __p=)
at /usr/include/c++/5/bits/alloc_traits.h:517
#8  std::_Vector_base, std::allocator >,
std::allocator,
std::allocator > > >::_M_deallocate (this=0x7fffc730,
__n=, __p=)
at /usr/include/c++/5/bits/stl_vector.h:178
#9  std::_Vector_base, std::allocator >,
std::allocator,
std::allocator > > >::~_Vector_base (this=0x7fffc730,
__in_chrg=) at /usr/include/c++/5/bits/stl_vector.h:160
#10 std::vector,
std::allocator >, std::allocator, std::allocator > > >::~vector
(this=0x7fffc730,
__in_chrg=) at /usr/include/c++/5/bits/stl_vector.h:425
#11 rld::path::path_abs (path=...) at ../rtemstoolkit/rld-path.cpp:132
#12 0x0042bc4a in rld::dwarf::compilation_unit::compilation_unit (
this=0x7fffca30, debug=..., die=..., offset=)
at ../rtemstoolkit/rld-dwarf.cpp:486
#13 0x0042d205 in rld::dwarf::file::load_debug (this=this@entry
=0x6bc568)
at ../rtemstoolkit/rld-dwarf.cpp:758
#14 0x0040dec5 in Coverage::ExecutableInfo::ExecutableInfo
(this=0x6bc3c0,
theExecutableName=, theLibraryName=0x0)
at ../tester/covoar/ExecutableInfo.cc:33
#15 0x004054b6 in main (argc=, argv=)
at ../tester/covoar/covoar.cc:330


On 7 May 2018 at 20:03, Joel Sherrill  wrote:

>
>
> On Mon, May 7, 2018 at 1:59 PM, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 7 May 2018 at 18:56, Joel Sherrill  wrote:
>>
>>> Hi
>>>
>>> I have attached a workaround. It seems that libgen.h has this:
>>>
>>> 
>>> /* Return final component of PATH.
>>>
>>>This is the weird XPG version of this function.  It sometimes will
>>>modify its argument.  Therefore we normally use the GNU version (in
>>>) and only if this header is included make the XPG
>>>version available under the real name.  */
>>> extern char *__xpg_basename (char *__path) __THROW;
>>> #define basename__xpg_basename
>>> 
>>>
>>> Chris has used basename as a method name and even though that should
>>> be perfectly acceptable, the macro above gets expanded, the name
>>> gets changed (in some places) to rld::path::__xpg_basename()
>>>
>>>   r.lowSourceLine = rld::path::basename (location);
>>>
>>> IMO the fix is to add dirname to rld-files, use rld basename and dirname
>>> exclusively, and avoid libgen.h at all costs.
>>>
>>> I didn't do that much work. I got lucky in a couple of files by removing
>>> the
>>> include of libgen.h since it wasn't needed but I had to leave it in one
>>> place.
>>>
>>> $ grep dirname *.cc
>>> GcovData.cc:dirname( path );
>>>
>>> Hopefully this lets you all proceed with Chris' patches and my slight
>>> hack
>>> in place.
>>>
>>
>> Thanks Joel! The good news is that's building now with only a couple of
>> warnings.
>>
>> The bad news is..
>>
>> cpod@cpod ~/development/rtems/leon3 $ covoar -S
>> /home/cpod/development/rtems/test/rtems-tools/tester/rtems/t
>> esting/coverage/score-symbols.ini -O /home/cpod/coverage_test/test/score
>> -E/home/cpod/development/rtems/test/rtems-tools/tester/rtems
>> /testing/coverage/Explanations.txt -p RTEMS-5 -v
>> sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>> *** Error in `covoar': free(): invalid next size (fast):
>> 0x01000360 ***
>> === Backtrace: =
>> /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7fcd0b3477e5]
>> /lib/x86_64-linux-gnu/libc.s

Re: Fwd: [PATCH 2/4] covoar: Use DWARF to map addresses to source files and lines.

[Cillian O'Donnell]

pilation_unit(rld::dwarf::file&,
rld::dwarf::debug_info_entry&, unsigned long) (rld-dwarf.cpp:486)
==20928==by 0x42D204: rld::dwarf::file::load_debug() (rld-dwarf.cpp:758)
==20928==by 0x40DEC4: Coverage::ExecutableInfo::ExecutableInfo(char
const*, char const*) (ExecutableInfo.cc:33)
==20928==by 0x4054B5: main (covoar.cc:330)
==20928==  If you believe this happened as a result of a stack
==20928==  overflow in your program's main thread (unlikely but
==20928==  possible), you can try to increase the size of the
==20928==  main thread stack using the --main-stacksize= flag.
==20928==  The main thread stack size used in this run was 8388608.
==20928==
==20928== HEAP SUMMARY:
==20928== in use at exit: 6,603,094 bytes in 39,763 blocks
==20928==   total heap usage: 98,260 allocs, 58,498 frees, 8,844,293 bytes
allocated
==20928==
==20928== LEAK SUMMARY:
==20928==definitely lost: 55 bytes in 3 blocks
==20928==indirectly lost: 0 bytes in 0 blocks
==20928==  possibly lost: 0 bytes in 0 blocks
==20928==still reachable: 6,603,039 bytes in 39,760 blocks
==20928== suppressed: 0 bytes in 0 blocks
==20928== Rerun with --leak-check=full to see details of leaked memory
==20928==
==20928== For counts of detected and suppressed errors, rerun with: -v
==20928== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Segmentation fault


On 7 May 2018 at 20:16, Cillian O'Donnell  wrote:

> Heres the gdb backtrace. rld-dwarf.cpp rld-path showing up near the
> bottom. I don't have valgrind, I'll get it now and see what I find there.
>
> (gdb) bt
> #0  0x774aa428 in __GI_raise (sig=sig@entry=6)
> at ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x774ac02a in __GI_abort () at abort.c:89
> #2  0x774ec7ea in __libc_message (do_abort=do_abort@entry=2,
> fmt=fmt@entry=0x77605ed8 "*** Error in `%s': %s: 0x%s ***\n")
> at ../sysdeps/posix/libc_fatal.c:175
> #3  0x774f537a in malloc_printerr (ar_ptr=,
> ptr=, str=0x77605f50 "free(): invalid next size
> (fast)",
> action=3) at malloc.c:5006
> #4  _int_free (av=, p=, have_lock=0) at
> malloc.c:3867
> #5  0x774f953c in __GI___libc_free (mem=) at
> malloc.c:2968
> #6  0x0043fcee in 
> __gnu_cxx::new_allocator std::char_traits, std::allocator > >::deallocate
> (this=0x7fffc730,
> __p=) at /usr/include/c++/5/ext/new_allocator.h:110
> #7  std::allocator_traits std::char_traits, std::allocator > > >::deallocate (__a=...,
> __n=, __p=)
> at /usr/include/c++/5/bits/alloc_traits.h:517
> #8  std::_Vector_base std::char_traits, std::allocator >,
> std::allocator,
> std::allocator > > >::_M_deallocate (this=0x7fffc730,
> __n=, __p=)
> at /usr/include/c++/5/bits/stl_vector.h:178
> #9  std::_Vector_base std::char_traits, std::allocator >,
> std::allocator,
> std::allocator > > >::~_Vector_base (this=0x7fffc730,
> __in_chrg=) at /usr/include/c++/5/bits/stl_vector.h:160
> #10 std::vector,
> std::allocator >, std::allocator std::char_traits, std::allocator > > >::~vector
> (this=0x7fffc730,
> __in_chrg=) at /usr/include/c++/5/bits/stl_vector.h:425
> #11 rld::path::path_abs (path=...) at ../rtemstoolkit/rld-path.cpp:132
> #12 0x0042bc4a in rld::dwarf::compilation_unit::compilation_unit (
> this=0x7fffca30, debug=..., die=..., offset=)
> at ../rtemstoolkit/rld-dwarf.cpp:486
> #13 0x0042d205 in rld::dwarf::file::load_debug (this=this@entry
> =0x6bc568)
> at ../rtemstoolkit/rld-dwarf.cpp:758
> #14 0x0040dec5 in Coverage::ExecutableInfo::ExecutableInfo
> (this=0x6bc3c0,
> theExecutableName=, theLibraryName=0x0)
> at ../tester/covoar/ExecutableInfo.cc:33
> #15 0x004054b6 in main (argc=, argv=)
> at ../tester/covoar/covoar.cc:330
>
>
> On 7 May 2018 at 20:03, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, May 7, 2018 at 1:59 PM, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 7 May 2018 at 18:56, Joel Sherrill  wrote:
>>>
>>>> Hi
>>>>
>>>> I have attached a workaround. It seems that libgen.h has this:
>>>>
>>>> 
>>>> /* Return final component of PATH.
>>>>
>>>>This is the weird XPG version of this function.  It sometimes will
>>>>modify its argument.  Therefore we normally use the GNU version (in
>>>>) and only if this header is included make the XPG
>>>>version available under the real name.  */
>>>> extern char *__xpg_basename (char *__path) __THROW;
>>>

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

[Cillian O'Donnell]

Just running covoar there, we seem to be running into some problems at the
source line lookup stage

cpod@cpod ~/development/rtems/leon3 $ covoar -S
/home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/score-symbols.ini
-O /home/cpod/coverage_test/test/score
-E/home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/Explanations.txt
-p RTEMS-5 -v sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Processing multiple executable/coverage file pairs
Coverage Format : html
Target  : sparc-rtems5

Coverage file sparc-rtems5/c/leon3/testsuites/samples/hello/hello.cov for
executable: sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Loading symbol sets:
/home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/score-symbols.ini
 Symbol set: score
 Loading library: sparc-rtems5/c/leon3/cpukit/score/libscore.a
cache:load-sym: object files: 192
cache:load-sym: symbols: 382
Analyzing 382 symbols
Extracting information from:
sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Created unified coverage map for _RTEMS_Lock_allocator (0x0 - 0x13)
Created unified coverage map for _RTEMS_Unlock_allocator (0x0 - 0x13)
Created unified coverage map for _API_Mutex_Lock (0x0 - 0x2f)
Created unified coverage map for _API_Mutex_Unlock (0x0 - 0x2f)
Created unified coverage map for _Chain_Initialize (0x0 - 0x4f)
Created unified coverage map for _Freechain_Initialize (0x0 - 0x33)
Created unified coverage map for _Freechain_Get (0x0 - 0x77)
Created unified coverage map for _Freechain_Put (0x0 - 0x27)
Created unified coverage map for _Heap_Allocate_aligned_with_boundary (0x0
- 0x23f)

...
...
Branch always taken found in_Workspace_Handler_initialization (0x4000ab8c -
0x4000ab8f)
Branch never taken found in _Workspace_Handler_initialization (0x1073785764
- 0x1073785767)
Branch never taken found in _Workspace_Handler_initialization (0x1073785776
- 0x1073785779)
Calculate statistics
Looking up source lines for uncovered ranges and branches
Looking up source lines for uncovered ranges in CSWTCH.1
terminate called after throwing an instance of 'rld::error'
Aborted


GDB


(gdb) bt
#0  0x774aa428 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x774ac02a in __GI_abort () at abort.c:89
#2  0x77ae484d in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x77ae26b6 in ?? () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x77ae2701 in std::terminate() ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x77ae2919 in __cxa_throw ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x0042ad4a in rld::dwarf::address::path[abi:cxx11]() const (
this=this@entry=0x7fffcc10) at ../rtemstoolkit/rld-dwarf.cpp:129
#7  0x0042dfad in rld::dwarf::file::get_source
(this=this@entry=0x6be568,

addr=, source_file="unknown",
source_line=@0x7fffccdc: -1)
at ../rtemstoolkit/rld-dwarf.cpp:860
#8  0x0040d541 in Coverage::ExecutableInfo::getSourceAndLine (
this=this@entry=0x6be3c0, address=, line="")
at ../tester/covoar/ExecutableInfo.cc:134
#9  0x0040a115 in Coverage::DesiredSymbols::determineSourceLines (
this=this@entry=0xafee70, theRanges=theRanges@entry=0xd626f0,
theExecutable=0x6be3c0) at ../tester/covoar/DesiredSymbols.cc:411
#10 0x0040a24f in Coverage::DesiredSymbols::findSourceForUncovered (
this=0xafee70) at ../tester/covoar/DesiredSymbols.cc:440
#11 0x00406028 in main (argc=, argv=)
at ../tester/covoar/covoar.cc:526

I'll attach a trace file I'm using to debug, hopefully you can use this. It
has to go with hello.exe in the build directory

All the best,

Cillian.


On 8 May 2018 at 06:09, Chris Johns  wrote:

> Hi,
>
> This is a wrap up patch of all the issues that have been raise. Thanks to
> the excellent debugging and teamwork in finding the linking issue on Linux,
> that is a really strange one to trip over.
>
> The patches:
>
> - Add a DWARF framework to the rtemstoolkit to access the
>   source file and line given an address in an executable. This allows
>   us to remove exec'ing addr2line in covoar.
>
> - Add producer support to rtems-exe-info to list the compilers used
>   to build the executables plus list the common flags and optionally
>   list all the object files with the flags that are not common.
>
> - Clean up exception handling in destructors in some places. This
>   avoids a terminate if an exception is thrown in an exception
>   unwind.
>
> Changes since v1:
>
> - Fix rld::path::path_abs() to not walk above the root directory.
>
> - Fix a memory issue with the dwarf_srcfiles(). The libdwarf we are
>   using manages all memory and does not need to have it dealloced
>   while the man pages state it should be.
>
> - Add producer support to collect and manag

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

[Cillian O'Donnell]

On Thu, 10 May 2018, 03:43 Chris Johns,  wrote:

> On 10/5/18 8:47 am, Cillian O'Donnell wrote:
> > Just running covoar there, we seem to be running into some problems at
> the
> > source line lookup stage
>
> Thank you for testing this. I assume it builds OK and we can run it?
>

Builds with a couple of warnings, other than that it's fine. Hopefully no
issues on freebsd.

>
> > cpod@cpod ~/development/rtems/leon3 $ covoar -S
> >
> /home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/score-symbols.ini
> > -O /home/cpod/coverage_test/test/score
> >
> -E/home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/Explanations.txt
> > -p RTEMS-5 -v sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
> > Processing multiple executable/coverage file pairs
> > Coverage Format : html
> > Target  : sparc-rtems5
> >
> > Coverage file sparc-rtems5/c/leon3/testsuites/samples/hello/hello.cov for
> > executable: sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
> > Loading symbol sets:
> >
> /home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/score-symbols.ini
> >  Symbol set: score
> >  Loading library: sparc-rtems5/c/leon3/cpukit/score/libscore.a
> > cache:load-sym: object files: 192
> > cache:load-sym: symbols: 382
> > Analyzing 382 symbols
> > Extracting information from:
> sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
> > Created unified coverage map for _RTEMS_Lock_allocator (0x0 - 0x13)
> > Created unified coverage map for _RTEMS_Unlock_allocator (0x0 - 0x13)
> > Created unified coverage map for _API_Mutex_Lock (0x0 - 0x2f)
> > Created unified coverage map for _API_Mutex_Unlock (0x0 - 0x2f)
> > Created unified coverage map for _Chain_Initialize (0x0 - 0x4f)
> > Created unified coverage map for _Freechain_Initialize (0x0 - 0x33)
> > Created unified coverage map for _Freechain_Get (0x0 - 0x77)
> > Created unified coverage map for _Freechain_Put (0x0 - 0x27)
> > Created unified coverage map for _Heap_Allocate_aligned_with_boundary
> (0x0 - 0x23f)
> > 
> > ...
> > ...
> > Branch always taken found in_Workspace_Handler_initialization
> (0x4000ab8c -
> > 0x4000ab8f)
> > Branch never taken found in _Workspace_Handler_initialization
> (0x1073785764 -
> > 0x1073785767)
> > Branch never taken found in _Workspace_Handler_initialization
> (0x1073785776 -
> > 0x1073785779)
> > Calculate statistics
> > Looking up source lines for uncovered ranges and branches
> > Looking up source lines for uncovered ranges in CSWTCH.1
> > terminate called after throwing an instance of 'rld::error'
> > Aborted
> >
> > 
> > GDB
> > 
> >
> > (gdb) bt
> > #0  0x774aa428 in __GI_raise (sig=sig@entry=6)
> > at ../sysdeps/unix/sysv/linux/raise.c:54
> > #1  0x774ac02a in __GI_abort () at abort.c:89
> > #2  0x77ae484d in __gnu_cxx::__verbose_terminate_handler() ()
> >from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> > #3  0x77ae26b6 in ?? () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> > #4  0x77ae2701 in std::terminate() ()
> >from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> > #5  0x77ae2919 in __cxa_throw ()
> >from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> > #6  0x0042ad4a in rld::dwarf::address::path[abi:cxx11]() const (
> > this=this@entry=0x7fffcc10) at ../rtemstoolkit/rld-dwarf.cpp:129
> > #7  0x0042dfad in rld::dwarf::file::get_source (this=this@entry
> =0x6be568,
> > addr=, source_file="unknown",
> source_line=@0x7fffccdc: -1)
> > at ../rtemstoolkit/rld-dwarf.cpp:860
> > #8  0x0040d541 in Coverage::ExecutableInfo::getSourceAndLine (
> > this=this@entry=0x6be3c0, address=, line="")
> > at ../tester/covoar/ExecutableInfo.cc:134
> > #9  0x0040a115 in Coverage::DesiredSymbols::determineSourceLines
> (
> > this=this@entry=0xafee70, theRanges=theRanges@entry=0xd626f0,
> > theExecutable=0x6be3c0) at ../tester/covoar/DesiredSymbols.cc:411
> > #10 0x0040a24f in
> Coverage::DesiredSymbols::findSourceForUncovered (
> > this=0xafee70) at ../tester/covoar/DesiredSymbols.cc:440
> > #11 0x00406028 in main (argc=, argv= out>)
> > at ../tester/covoar/covoar.cc:526
>
> This looks like an exception being thrown in a destructor path.
>
> >
> > I'll attach a trace file I'm using to debug, hopefully you can use this.
> It has
> > to go with hello.exe in the build directory
>
> Thank you for this. I will try and see what I find.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: [PATCH 2/4] covoar: Use DWARF to map addresses to source files and lines.

[Cillian O'Donnell]

On Thu, 10 May 2018, 16:01 Vijay Kumar Banerjee, 
wrote:

>
>
> On 8 May 2018 at 00:33, Cillian O'Donnell  wrote:
>
>> Here's the branch with work in progress for the tester. Have a look when
>> you can Vijay.
>>
>> https://github.com/cillianodonnell/rtems-tools/tree/tester-support
>>
>>
>> I am going through this now.
> according to your last commit message, the qemu.cfg is not generating cov
> files.
>

The commit message was just a note to myself to check if that was the case.
Sorry forgot to mention we used to search for exe.cov and with Chris'
changes its now searching for .cov. Have to change the name that's passed
to the qemu cmd to fix that. You could try and change that.

Just to see where it stands, I run the rtems-test with --coverage and
> --no-clean, seems like the cov file is being generated .
> I can see a base_sp.exe.cov file after running for base_sp.exe the reason
> why it's not running is probably because covoar is searching for
> base_sp.cov not base_sp.exe.cov
>
> after renaming the file to base_sp.cov and running covoar from the leon3
> directory I was able to reproduce the same error as you
> ...
> ...
> ...
> terminate called after throwing an instance of 'rld::error'
> Aborted
> .
> .
> .
>
> I think the next part of the tester support will be to load the library
> from out of the build directory. (?)
>

I wouldn't even worry about that for the moment. Just getting the tester to
run covoar with no errors and generate a report with data intact would be
good enough to throw up the patches for a first review and then we can see
what else needs to be done.

>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Cillian O'Donnell]

On Thu, 10 May 2018, 11:48 Chris Johns,  wrote:

> On 10/5/18 2:43 pm, Chris Johns wrote:
> > On 10/5/18 8:47 am, Cillian O'Donnell wrote:
> >>
> >> 
> >> GDB
> >> 
> >>
> >> (gdb) bt
> >> #0  0x774aa428 in __GI_raise (sig=sig@entry=6)
> >> at ../sysdeps/unix/sysv/linux/raise.c:54
> >> #1  0x774ac02a in __GI_abort () at abort.c:89
> >> #2  0x77ae484d in __gnu_cxx::__verbose_terminate_handler() ()
> >>from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> >> #3  0x77ae26b6 in ?? () from
> /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> >> #4  0x77ae2701 in std::terminate() ()
> >>from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> >> #5  0x77ae2919 in __cxa_throw ()
> >>from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> >> #6  0x0042ad4a in rld::dwarf::address::path[abi:cxx11]() const (
> >> this=this@entry=0x7fffcc10) at
> ../rtemstoolkit/rld-dwarf.cpp:129
> >> #7  0x0042dfad in rld::dwarf::file::get_source (this=this@entry
> =0x6be568,
> >> addr=, source_file="unknown",
> source_line=@0x7fffccdc: -1)
> >> at ../rtemstoolkit/rld-dwarf.cpp:860
> >> #8  0x0040d541 in Coverage::ExecutableInfo::getSourceAndLine (
> >> this=this@entry=0x6be3c0, address=, line="")
> >> at ../tester/covoar/ExecutableInfo.cc:134
> >> #9  0x0040a115 in
> Coverage::DesiredSymbols::determineSourceLines (
> >> this=this@entry=0xafee70, theRanges=theRanges@entry=0xd626f0,
> >> theExecutable=0x6be3c0) at ../tester/covoar/DesiredSymbols.cc:411
> >> #10 0x0040a24f in
> Coverage::DesiredSymbols::findSourceForUncovered (
> >> this=0xafee70) at ../tester/covoar/DesiredSymbols.cc:440
> >> #11 0x00406028 in main (argc=, argv= out>)
> >> at ../tester/covoar/covoar.cc:526
> >
> > This looks like an exception being thrown in a destructor path.
> >
>
> I can reproduce this on MacOS with the hello.cov file. Thank you for it.
>

Cool was hoping that would work for you. Quicker debugging without me as
man in the middle.

>
> It is not a exception in an exception or in a stack unwind path, it is an
> exception being thrown with no catch.
>
> The covoar `main()` is  like C with return vales, stderr prints and exits
> or
> there are calls to exit in some paths taken from main. The RLD code
> expects a
> top level single catch which prints a message to stderr then exits. It is
> mixing
> this these two approaches which resulted in no catch. I am so use to not
> needing
> to think about it. Maybe I should look at main and clean it up.
>

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?

>
> I also need to figure out why the address has lost it's reference to the
> source
> table.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Cillian O'Donnell]

On 10 May 2018 at 19:39, Chris Johns  wrote:

> On 11/5/18 5:37 am, Cillian O'Donnell wrote:
> > On Thu, 10 May 2018, 11:48 Chris Johns,  >
> > It is not a exception in an exception or in a stack unwind path, it
> is an
> > exception being thrown with no catch.
> >
> > The covoar `main()` is  like C with return vales, stderr prints and
> exits or
> > there are calls to exit in some paths taken from main. The RLD code
> expects a
> > top level single catch which prints a message to stderr then exits.
> It is mixing
> > this these two approaches which resulted in no catch. I am so use to
> not needing
> > to think about it. Maybe I should look at main and clean it up.
> >
> >
> > 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?
>
> Thank for you the offer. The change to main is in response to my changes
> to add
> DWARF support and those changes are not yet working so I feel I have to
> make the
> change as part of this work or Vijay ends up on my broken version of
> rtems-tools
> and that is not productive.
>
> I also think the other listed work is better value for us and more fun for
> Vijay. :)
>

Fair enough :) I thought you might want to lighten your load. You're doing
all the heavy lifting.


>
> I have moved my changes to a personal repo to make it easier to manage:
>
>  https://git.rtems.org/chrisj/rtems-tools.git/?h=covoar-dwarf
>
> I think the git commands to use are:
>
>  $ git remote add chrisj git://git.rtems.org/chrisj/rtems-tools.git
>  $ git fetch chrisj
>
> You should then be able to see the 'covoar-dwarf' branch. I have not tested
> these commands.
>
> Chris
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Cillian O'Donnell]

On 10 May 2018 at 20:15, Vijay Kumar Banerjee 
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.


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

>
>
> On 10 May 2018 at 23:40, Joel Sherrill  wrote:
>
>> On Thu, May 10, 2018 at 12:37 PM, Cillian O'Donnell <
>> cpodonne...@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@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>>
>>
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: 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, 
wrote:

>
>
> On Fri, 11 May 2018, 02:19 Cillian O'Donnell, 
> wrote:
>
>>
>>
>> On 10 May 2018 at 20:15, Vijay Kumar Banerjee 
>> 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  wrote:
>>>
>>>> On Thu, May 10, 2018 at 12:37 PM, Cillian O'Donnell <
>>>> cpodonne...@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
&g

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

[Cillian O'Donnell]

On Fri, 11 May 2018, 06:17 Chris Johns,  wrote:

> On 11/5/18 4:44 pm, Chris Johns wrote:
> >
> > I am looking into the reason for the error which is proving difficult to
> find.
> >
>
> Cillian, could you please compress and email me offlist the ELF file for
> the cov
> file is for?
>

Will do. It'll be tonight before I'm near that machine though.

>
> Thanks
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Cillian O'Donnell]

Ah NZ almost exact opposite sides of the world, that worked out nicely.

On Fri, 11 May 2018, 07:54 Chris Johns,  wrote:

>
> On 11 May 2018, at 6:21 pm, Cillian O'Donnell 
> wrote:
>
>
>
> On Fri, 11 May 2018, 06:17 Chris Johns,  wrote:
>
>> On 11/5/18 4:44 pm, Chris Johns wrote:
>> >
>> > I am looking into the reason for the error which is proving difficult
>> to find.
>> >
>>
>> Cillian, could you please compress and email me offlist the ELF file for
>> the cov
>> file is for?
>>
>
> Will do. It'll be tonight before I'm near that machine though.
>
>
> That will be fine. I am in NZ at the moment so it is getting late.
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar: fixing the extension mismatch in trace file

[Cillian O'Donnell]

It does seem to be having some knock on effect. Covoar made it past these
checks before.

-
Total: 13
Average test time: 0:00:03.178923
Testing time : 0:00:41.326000
Running covoar for score
covoar results directory:
/home/cpod/development/rtems/leon3/coverage/score
ERROR: executable build prefix does not match: sparc-rtems5
***Cleaning tempfiles***
error: covoar failure exit code: 1

Not sure how thats related.

Its checking

 if (buildPrefix.empty()) {
 76   buildPrefix =
*pri;
 77 } else
{
 78   if (buildPrefix != *pri)
{
 79 std::cout << "buildBSP: " + buildBSP << "\n*pri: " + *pri
<< std::en
dl;
 80 fail = "executable build prefix does not match: " +
buildPrefix;
 81
break;
 82
}
 83 }

I added those checks, Its stepping back through the path and checking if
each directory makes sense. It seems to be out of line now

ERROR: executable build prefix does not match: sparc-rtems5
buildBSP: leon3
*pri: sparc-rtems5
***Cleaning tempfiles***

Maybe its splitting the path on '.' and '/' Haven't checked it yet.

On 13 May 2018 at 07:05, Vijay Kumar Banerjee 
wrote:

>
> On 13 May 2018 at 10:50, Chris Johns  wrote:
>
>> On 13/5/18 4:44 pm, Vijay Kumar Banerjee wrote:
>> > On Sun, 13 May 2018, 10:09 Chris Johns, > > > wrote:
>> > >
>> > >Coverage::CoverageFormats_t   coverageFormat =
>> > > Coverage::COVERAGE_FORMAT_QEMU;
>> > >Coverage::CoverageReaderBase* coverageReader = NULL;
>> > >char* executable = NULL;
>> > > @@ -317,11 +317,12 @@ int main(
>> > >  std::cerr << "warning: Unable to read executable: "
>> << argv[i] <<
>> > > std::endl;
>> > >} else {
>> > >  coverageFileName = argv[i];
>> > > -coverageFileName.replace(
>> > > +   coverageFileName.append(coverageExtension);
>> > > + /* coverageFileName.replace(
>> > >coverageFileName.length() -
>> executableExtension.size(),
>> > >executableExtension.size(),
>> > >coverageExtension
>> > > -);
>> > > +); */
>> > >
>> > >
>> > >
>> > > If you are replacing this call, then just delete it -- don't
>> comment it out.
>> > >
>> >
>> > I suggest the replace be changed to move past the '.' in the file
>> name.
>> >
>> > I suspect the code here is still fragile because the extensions
>> need to be the
>> > same size.
>> >
>> > can't this be done by adding '.' in the append as in the v2 of this
>> patch to
>> > keep the extension size same  ?
>>
>> It fixes something but what is broken that is being fixed?
>>
>> the trace files have .exe.cov extensions but the covoar was searching for
> .cov extension causing it to return error for not finding the trace file.
> Adding the .cov to the coverageFileName to make it .exe.cov seemed like a
> quick fix to this .
>
> Do we need the .exe extension there ?
>
> > are you suggesting to use replace instead ?
>>
>> I think it would be better to fix the bug than work around it.
>>
>> The replace is saying replace from length of the extension back from the
>> end of
>> the string for the size of the extension with the extension. In other
>> words it
>> should back up from the end the extension length and replace it. Which
>> length or
>> size is wrong.
>>
>> No matter what the current code is fragile because it assumes a few
>> things. The
>> most robust approach would add code to the rtemstoolkit's rld::path
>> namespace to
>> return a path with the extension stripped. For example add
>> 'rld::path::strip_extension ()' and then use that to strip
>> coverageFileName and
>> then add the extension.
>>
>> I would also review the 'exe' extension usage to make sure it is OK. I
>> have not
>> done this.
>>
>> Are you interested in doing this?
>>
>
> I can look into this. Any instructions ?
>
>>
>> Chris
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar: fixing the extension mismatch in trace file

[Cillian O'Donnell]

But you see the thing is that if you remove the changes you made and run
the tester from the top of the build tree it makes it past those checks and
does full coverage analysis runs for all trace files that end in only .cov.
So only hello.cov here because I've changed it manually.

warning: Unable to read coverage file:
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.cov
Processing multiple executable/coverage file pairs
Coverage Format : html
Target  : sparc-rtems5

Coverage file
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.cov
for executable:
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Loading symbol sets:
/home/cpod/development/rtems/test/rtems-tools/tester/rtems/testing/coverage/score-symbols.ini
 Symbol set: score
 Loading library: sparc-rtems5/c/leon3/cpukit/score/libscore.a
Analyzing 382 symbols
Extracting information from:
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Created unified coverage map for _RTEMS_Lock_allocator (0x0 - 0x13)
Created unified coverage map for _RTEMS_Unlock_allocator (0x0 - 0x13)
Created unified coverage map for _API_Mutex_Lock (0x0 - 0x2f)
..
Processing coverage file
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.cov
for executable
/home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
Preprocess uncovered ranges and branches
Computing uncovered ranges and branches
Branch always taken found in _API_Mutex_Lock (0x40005f98 - 0x40005f9b)
Branch always taken found in _API_Mutex_Unlock (0x40005fc0 - 0x40005fc3)
Branch never taken found in _Chain_Initialize (0x4000600c - 0x4000600f)
Branch always taken found in _Freechain_Get (0x40006070 - 0x40006073)
Branch never taken found in _Freechain_Get (0x40006084 - 0x40006087)
Branch never taken found in _Heap_Allocate_aligned_with_boundary
(0x40006108 - 0x4000610b)

Calculate statistics
Looking up source lines for uncovered ranges and branches
Looking up source lines for uncovered ranges in CSWTCH.1
Looking up source lines for uncovered branches in _API_Mutex_Lock
Looking up source lines for uncovered ranges in _API_Mutex_Unlock
Looking up source lines for uncovered branches in _API_Mutex_Unlock
Looking up source lines for uncovered branches in _Chain_Initialize
Looking up source lines for uncovered ranges in _Freechain_Get

Generate Reports
Generate index.txt
Generate annotated.txt
Generate branch.txt
Generate uncovered.txt
Generate sizes.txt
Generate symbolSummary.txt
Generate index.html
Generate annotated.html
Generate branch.html
Generate uncovered.html
Generate sizes.html
Generate symbolSummary.html
Writing Not Found Report
(/home/cpod/development/rtems/leon3/coverage/score/ExplanationsNotFound.txt)
Coverage run for score finished successfully.
---
Generating reports
Coverage analysis finished. You can find results in
/home/cpod/development/rtems/leon3
***Cleaning tempfiles***

So there does seem to be some knock on effect of just tacking on .cov
there. Can't see all the consequences immediately but I'm having a look
now. I'll let you know if I find anything.



On 13 May 2018 at 12:07, Vijay Kumar Banerjee 
wrote:

>
>
> On 13 May 2018 at 16:16, Vijay Kumar Banerjee 
> wrote:
>
>>
>>
>> On Sun, 13 May 2018, 16:15 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sun, 13 May 2018, 16:09 Cillian O'Donnell, 
>>> wrote:
>>>
>>>> It does seem to be having some knock on effect. Covoar made it past
>>>> these checks before.
>>>>
>>>> -
>>>> Total: 13
>>>> Average test time: 0:00:03.178923
>>>> Testing time : 0:00:41.326000
>>>> Running covoar for score
>>>> covoar results directory:
>>>> /home/cpod/development/rtems/leon3/coverage/score
>>>> ERROR: executable build prefix does not match: sparc-rtems5
>>>> ***Cleaning tempfiles***
>>>> error: covoar failure exit code: 1
>>>>
>>>> Not sure how thats related.
>>>>
>>>> Its checking
>>>>
>>>>  if (buildPrefix.empty()) {
>>>>
>>>>  76   buildPrefix = *pri;
>>>>
>>>>  77 } else {
>>>>
>>>>  78   if (buildPrefix != *pri) {
>>>>
>>>>  79 std::cout << "buildBSP: " + buildBSP << "\n*pri: " +
>>>> *pri << std::en
>>>> dl;
>>>>  

Re: [PATCH] covoar: fixing the extension mismatch in trace file

[Cillian O'Donnell]

I understand but that's a separate issue. I can do a full coverage run from
the top of the build tree by changing hello.exe.cov to hello.cov manually
using current master. Then I add your patch which is supposed to fix the
problem of having to change those manually so it looks for hello.exe.cov
instead but I can't even make it to the point of doing the coverage runs
anymore so it must of  had some unintended consequences.

I know its frustrating to work on a problem for a while and you finally
come up with the solution only to have all of us complain that it's not
quite right but that's just collaborative development, you'll have to get
used to it :)...

On 13 May 2018 at 12:39, Vijay Kumar Banerjee 
wrote:

>
>
> On Sun, 13 May 2018, 17:02 Cillian O'Donnell, 
> wrote:
>
>> But you see the thing is that if you remove the changes you made and run
>> the tester from the top of the build tree it makes it past those checks and
>> does full coverage analysis runs for all trace files that end in only .cov.
>> So only hello.cov here because I've changed it manually.
>>
> from the top of the build tree, it does work if you just manually change
> the extension .
> But it doesn't building from outside the directory, say from coverage_test
> directory . The change I'm suggesting is to make it work from there .
> For that we need to take the absolute path of the lib . maybe by
> implementing something like realpath() from rld::path will do it.
>
>>
>> warning: Unable to read coverage file: /home/cpod/development/rtems/
>> leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.cov
>> Processing multiple executable/coverage file pairs
>> Coverage Format : html
>> Target  : sparc-rtems5
>>
>> Coverage file /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/
>> testsuites/samples/hello/hello.cov for executable:
>> /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/
>> testsuites/samples/hello/hello.exe
>> Loading symbol sets: /home/cpod/development/rtems/
>> test/rtems-tools/tester/rtems/testing/coverage/score-symbols.ini
>>  Symbol set: score
>>  Loading library: sparc-rtems5/c/leon3/cpukit/score/libscore.a
>> Analyzing 382 symbols
>> Extracting information from: /home/cpod/development/rtems/
>> leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>> Created unified coverage map for _RTEMS_Lock_allocator (0x0 - 0x13)
>> Created unified coverage map for _RTEMS_Unlock_allocator (0x0 - 0x13)
>> Created unified coverage map for _API_Mutex_Lock (0x0 - 0x2f)
>> ..
>> Processing coverage file /home/cpod/development/rtems/
>> leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.cov for
>> executable /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/
>> testsuites/samples/hello/hello.exe
>> Preprocess uncovered ranges and branches
>> Computing uncovered ranges and branches
>> Branch always taken found in _API_Mutex_Lock (0x40005f98 - 0x40005f9b)
>> Branch always taken found in _API_Mutex_Unlock (0x40005fc0 - 0x40005fc3)
>> Branch never taken found in _Chain_Initialize (0x4000600c - 0x4000600f)
>> Branch always taken found in _Freechain_Get (0x40006070 - 0x40006073)
>> Branch never taken found in _Freechain_Get (0x40006084 - 0x40006087)
>> Branch never taken found in _Heap_Allocate_aligned_with_boundary
>> (0x40006108 - 0x4000610b)
>> 
>> Calculate statistics
>> Looking up source lines for uncovered ranges and branches
>> Looking up source lines for uncovered ranges in CSWTCH.1
>> Looking up source lines for uncovered branches in _API_Mutex_Lock
>> Looking up source lines for uncovered ranges in _API_Mutex_Unlock
>> Looking up source lines for uncovered branches in _API_Mutex_Unlock
>> Looking up source lines for uncovered branches in _Chain_Initialize
>> Looking up source lines for uncovered ranges in _Freechain_Get
>> 
>> Generate Reports
>> Generate index.txt
>> Generate annotated.txt
>> Generate branch.txt
>> Generate uncovered.txt
>> Generate sizes.txt
>> Generate symbolSummary.txt
>> Generate index.html
>> Generate annotated.html
>> Generate branch.html
>> Generate uncovered.html
>> Generate sizes.html
>> Generate symbolSummary.html
>> Writing Not Found Report (/home/cpod/development/rtems/
>> leon3/coverage/score/ExplanationsNotFound.txt)
>> Coverage run for score finished successfully.
>> ---
>> Generating reports
>> Coverage analysis finished. You can find results in
>> 

Re: [PATCH] covoar: fixing the extension mismatch in trace file

[Cillian O'Donnell]

On 13 May 2018 at 13:35, Vijay Kumar Banerjee 
wrote:

>
> On Sun, 13 May 2018, 17:32 Cillian O'Donnell, 
> wrote:
>
>> I understand but that's a separate issue. I can do a full coverage run
>> from the top of the build tree by changing hello.exe.cov to hello.cov
>> manually using current master. Then I add your patch which is supposed to
>> fix the problem of having to change those manually so it looks for
>> hello.exe.cov instead but I can't even make it to the point of doing the
>> coverage runs anymore so it must of  had some unintended consequences.
>>
>
> it's building fine here.
>

Does it only work if you change the path in the ini file?


> have you tried ./waf build install after the changes to covoar.cc?
>
> can you please try the v2 of the patch, ./waf build install it and see if
> it's behaving the same ?
>
>
>> I know its frustrating to work on a problem for a while and you finally
>> come up with the solution only to have all of us complain that it's not
>> quite right but that's just collaborative development, you'll have to get
>> used to it :)...
>>
> That's alright. :)
>
>>
>> On 13 May 2018 at 12:39, Vijay Kumar Banerjee 
>> wrote:
>>
>>>
>>>
>>> On Sun, 13 May 2018, 17:02 Cillian O'Donnell, 
>>> wrote:
>>>
>>>> But you see the thing is that if you remove the changes you made and
>>>> run the tester from the top of the build tree it makes it past those checks
>>>> and does full coverage analysis runs for all trace files that end in only
>>>> .cov. So only hello.cov here because I've changed it manually.
>>>>
>>> from the top of the build tree, it does work if you just manually change
>>> the extension .
>>> But it doesn't building from outside the directory, say from
>>> coverage_test directory . The change I'm suggesting is to make it work from
>>> there .
>>> For that we need to take the absolute path of the lib . maybe by
>>> implementing something like realpath() from rld::path will do it.
>>>
>>>>
>>>> warning: Unable to read coverage file: /home/cpod/development/rtems/
>>>> leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.cov
>>>> Processing multiple executable/coverage file pairs
>>>> Coverage Format : html
>>>> Target  : sparc-rtems5
>>>>
>>>> Coverage file /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/
>>>> testsuites/samples/hello/hello.cov for executable:
>>>> /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/
>>>> testsuites/samples/hello/hello.exe
>>>> Loading symbol sets: /home/cpod/development/rtems/
>>>> test/rtems-tools/tester/rtems/testing/coverage/score-symbols.ini
>>>>  Symbol set: score
>>>>  Loading library: sparc-rtems5/c/leon3/cpukit/score/libscore.a
>>>> Analyzing 382 symbols
>>>> Extracting information from: /home/cpod/development/rtems/
>>>> leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>>>> Created unified coverage map for _RTEMS_Lock_allocator (0x0 - 0x13)
>>>> Created unified coverage map for _RTEMS_Unlock_allocator (0x0 - 0x13)
>>>> Created unified coverage map for _API_Mutex_Lock (0x0 - 0x2f)
>>>> ..
>>>> Processing coverage file /home/cpod/development/rtems/
>>>> leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.cov for
>>>> executable /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/
>>>> testsuites/samples/hello/hello.exe
>>>> Preprocess uncovered ranges and branches
>>>> Computing uncovered ranges and branches
>>>> Branch always taken found in _API_Mutex_Lock (0x40005f98 - 0x40005f9b)
>>>> Branch always taken found in _API_Mutex_Unlock (0x40005fc0 - 0x40005fc3)
>>>> Branch never taken found in _Chain_Initialize (0x4000600c - 0x4000600f)
>>>> Branch always taken found in _Freechain_Get (0x40006070 - 0x40006073)
>>>> Branch never taken found in _Freechain_Get (0x40006084 - 0x40006087)
>>>> Branch never taken found in _Heap_Allocate_aligned_with_boundary
>>>> (0x40006108 - 0x4000610b)
>>>> 
>>>> Calculate statistics
>>>> Looking up source lines for uncovered ranges and branches
>>>> Looking up source lines for uncovered ranges in CSWTCH.1
>>>> Looking up source lines for uncove

Re: [PATCH] covoar: fixing the extension mismatch in trace file

[Cillian O'Donnell]

On 13 May 2018 at 13:47, Vijay Kumar Banerjee 
wrote:

>
> On Sun, 13 May 2018, 18:14 Cillian O'Donnell, 
> wrote:
>
>>
>>
>> On 13 May 2018 at 13:35, Vijay Kumar Banerjee 
>> wrote:
>>
>>>
>>> On Sun, 13 May 2018, 17:32 Cillian O'Donnell, 
>>> wrote:
>>>
>>>> I understand but that's a separate issue. I can do a full coverage run
>>>> from the top of the build tree by changing hello.exe.cov to hello.cov
>>>> manually using current master. Then I add your patch which is supposed to
>>>> fix the problem of having to change those manually so it looks for
>>>> hello.exe.cov instead but I can't even make it to the point of doing the
>>>> coverage runs anymore so it must of  had some unintended consequences.
>>>>
>>>
>>> it's building fine here.
>>>
>>
>> Does it only work if you change the path in the ini file?
>>
> if you're running from the top of leon3 build tree then Changing the path
> shouldn't be required.
>

I'm not but did you add the line to leon3-qemu-cov.ini that you mentioned
above and that's the reason it's working for you. If you change that back
to the original. Is is still working?

>
>>
>>> have you tried ./waf build install after the changes to covoar.cc?
>>>
>>> can you please try the v2 of the patch, ./waf build install it and see
>>> if it's behaving the same ?
>>>
>>>
>>>> I know its frustrating to work on a problem for a while and you finally
>>>> come up with the solution only to have all of us complain that it's not
>>>> quite right but that's just collaborative development, you'll have to get
>>>> used to it :)...
>>>>
>>> That's alright. :)
>>>
>>>>
>>>> On 13 May 2018 at 12:39, Vijay Kumar Banerjee >>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, 13 May 2018, 17:02 Cillian O'Donnell, 
>>>>> wrote:
>>>>>
>>>>>> But you see the thing is that if you remove the changes you made and
>>>>>> run the tester from the top of the build tree it makes it past those 
>>>>>> checks
>>>>>> and does full coverage analysis runs for all trace files that end in only
>>>>>> .cov. So only hello.cov here because I've changed it manually.
>>>>>>
>>>>> from the top of the build tree, it does work if you just manually
>>>>> change the extension .
>>>>> But it doesn't building from outside the directory, say from
>>>>> coverage_test directory . The change I'm suggesting is to make it work 
>>>>> from
>>>>> there .
>>>>> For that we need to take the absolute path of the lib . maybe by
>>>>> implementing something like realpath() from rld::path will do it.
>>>>>
>>>>>>
>>>>>> warning: Unable to read coverage file: /home/cpod/development/rtems/
>>>>>> leon3/sparc-rtems5/c/leon3/testsuites/samples/unlimited/unlimited.cov
>>>>>> Processing multiple executable/coverage file pairs
>>>>>> Coverage Format : html
>>>>>> Target  : sparc-rtems5
>>>>>>
>>>>>> Coverage file /home/cpod/development/rtems/
>>>>>> leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.cov for
>>>>>> executable: /home/cpod/development/rtems/leon3/sparc-rtems5/c/leon3/
>>>>>> testsuites/samples/hello/hello.exe
>>>>>> Loading symbol sets: /home/cpod/development/rtems/
>>>>>> test/rtems-tools/tester/rtems/testing/coverage/score-symbols.ini
>>>>>>  Symbol set: score
>>>>>>  Loading library: sparc-rtems5/c/leon3/cpukit/score/libscore.a
>>>>>> Analyzing 382 symbols
>>>>>> Extracting information from: /home/cpod/development/rtems/
>>>>>> leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>>>>>> Created unified coverage map for _RTEMS_Lock_allocator (0x0 - 0x13)
>>>>>> Created unified coverage map for _RTEMS_Unlock_allocator (0x0 - 0x13)
>>>>>> Created unified coverage map for _API_Mutex_Lock (0x0 - 0x2f)
>>>>>> ..
>>>>>> Processing coverage file /home/cpod/development/rtems/
>>>>>> leo

Re: [PATCH] covoar: fixing the extension mismatch in trace file

[Cillian O'Donnell]

Is there supposed to be a message there?

Anyway just to clear this up, try this for me.

1. Grab a new branch of

https://github.com/cillianodonnell/rtems-tools/tree/tester-support

which is the current master plus one patch with the tester support in
progress.

2. Apply your patch to that and make no other changes.

3. Build covoar again.

3. Run the tester from the top of the build tree and tell me what you see.

cpod@cpod ~/development/rtems/leon3 $
$HOME/development/rtems/test/rtems-tools/tester/rtems-test
--rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
--rtems-bsp=leon3-qemu-cov --coverage
$HOME/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples



On 13 May 2018 at 13:58, Vijay Kumar Banerjee 
wrote:

>
>
> On Sun, 13 May 2018, 18:24 Cillian O'Donnell, 
> wrote:
>
>>
>>
>> On 13 May 2018 at 13:47, Vijay Kumar Banerjee 
>> wrote:
>>
>>>
>>> On Sun, 13 May 2018, 18:14 Cillian O'Donnell, 
>>> wrote:
>>>
>>>>
>>>>
>>>> On 13 May 2018 at 13:35, Vijay Kumar Banerjee >>> > wrote:
>>>>
>>>>>
>>>>> On Sun, 13 May 2018, 17:32 Cillian O'Donnell, 
>>>>> wrote:
>>>>>
>>>>>> I understand but that's a separate issue. I can do a full coverage
>>>>>> run from the top of the build tree by changing hello.exe.cov to hello.cov
>>>>>> manually using current master. Then I add your patch which is supposed to
>>>>>> fix the problem of having to change those manually so it looks for
>>>>>> hello.exe.cov instead but I can't even make it to the point of doing the
>>>>>> coverage runs anymore so it must of  had some unintended consequences.
>>>>>>
>>>>>
>>>>> it's building fine here.
>>>>>
>>>>
>>>> Does it only work if you change the path in the ini file?
>>>>
>>> if you're running from the top of leon3 build tree then Changing the
>>> path shouldn't be required.
>>>
>>
>> I'm not but did you add the line to leon3-qemu-cov.ini that you mentioned
>> above and that's the reason it's working for you. If you change that back
>> to the original. Is is still working?
>>
>>>
>>>>
>>>>> have you tried ./waf build install after the changes to covoar.cc?
>>>>>
>>>>> can you please try the v2 of the patch, ./waf build install it and see
>>>>> if it's behaving the same ?
>>>>>
>>>>>
>>>>>> I know its frustrating to work on a problem for a while and you
>>>>>> finally come up with the solution only to have all of us complain that 
>>>>>> it's
>>>>>> not quite right but that's just collaborative development, you'll have to
>>>>>> get used to it :)...
>>>>>>
>>>>> That's alright. :)
>>>>>
>>>>>>
>>>>>> On 13 May 2018 at 12:39, Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, 13 May 2018, 17:02 Cillian O'Donnell, 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> But you see the thing is that if you remove the changes you made
>>>>>>>> and run the tester from the top of the build tree it makes it past 
>>>>>>>> those
>>>>>>>> checks and does full coverage analysis runs for all trace files that 
>>>>>>>> end in
>>>>>>>> only .cov. So only hello.cov here because I've changed it manually.
>>>>>>>>
>>>>>>> from the top of the build tree, it does work if you just manually
>>>>>>> change the extension .
>>>>>>> But it doesn't building from outside the directory, say from
>>>>>>> coverage_test directory . The change I'm suggesting is to make it work 
>>>>>>> from
>>>>>>> there .
>>>>>>> For that we need to take the absolute path of the lib . maybe by
>>>>>>> implementing something like realpath() from rld::path will do it.
>>>>>>>
>>>>>>>>
>>>>>>>> warning: Unable to read coverage file: /home/cpod/deve

Re: [PATCH] covoar: fixing the extension mismatch in trace file

[Cillian O'Donnell]

On 13 May 2018 at 16:32, Vijay Kumar Banerjee 
wrote:

> On 13 May 2018 at 19:00, Cillian O'Donnell  wrote:
>
>> Is there supposed to be a message there?
>>
>> Anyway just to clear this up, try this for me.
>>
>> 1. Grab a new branch of
>>
>> https://github.com/cillianodonnell/rtems-tools/tree/tester-support
>>
>> which is the current master plus one patch with the tester support in
>> progress.
>>
>> 2. Apply your patch to that and make no other changes.
>>
>> 3. Build covoar again.
>>
>> 3. Run the tester from the top of the build tree and tell me what you see.
>>
>> cpod@cpod ~/development/rtems/leon3 $ 
>> $HOME/development/rtems/test/rtems-tools/tester/rtems-test
>> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
>> --rtems-bsp=leon3-qemu-cov --coverage $HOME/development/rtems/leon3/
>> sparc-rtems5/c/leon3/testsuites/samples
>>
>>  Yes it's breaking .
> when used with a single executable say unlimited.exe , it works but when
> it's run with samples/ it returns the error :
> executable build prefix does not match : sparc-rtems5
>

Yeah that's the one I'm seeing. Right so the difference is actually single
or multiple executables. Interesting...

>
> That's strange .
> I think it has something to do with the parsing of the path from the ini
> file.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

---
 tester/covoar/covoar.cc | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
index 5c87402..c6b0589 100644
--- a/tester/covoar/covoar.cc
+++ b/tester/covoar/covoar.cc
@@ -75,7 +75,7 @@ static void createBuildPath(Executables& executablesToAnalyze,
 if (buildPrefix.empty()) {
   buildPrefix = *pri;
 } else {
-  if (buildBSP != *pri) {
+  if (buildPrefix != *pri) {
 fail = "executable build prefix does not match: " + buildPrefix;
 break;
   }
@@ -97,7 +97,7 @@ static void createBuildPath(Executables& executablesToAnalyze,
 if (buildPath.empty()) {
   buildPath = thisBuildPath;
 } else {
-  if (buildBSP != *pri) {
+  if (buildPath != thisBuildPath) {
 fail = "executable build path does not match: " + buildPath;
   }
 }
@@ -316,11 +316,7 @@ int main(
 std::cerr << "warning: Unable to read executable: " << argv[i] << 
std::endl;
   } else {
 coverageFileName = argv[i];
-coverageFileName.replace(
-  coverageFileName.length() - executableExtension.size(),
-  executableExtension.size(),
-  coverageExtension
-);
+coverageFileName.append( "." + coverageExtension );
 
 if (!FileIsReadable( coverageFileName.c_str() )) {
   std::cerr << "warning: Unable to read coverage file: " << 
coverageFileName
-- 
2.7.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sun, 13 May 2018, 22:15 Vijay Kumar Banerjee, 
wrote:

> On 14 May 2018 at 02:15, Cillian O'Donnell  wrote:
>
>> ---
>>  tester/covoar/covoar.cc | 10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
>> index 5c87402..c6b0589 100644
>> --- a/tester/covoar/covoar.cc
>> +++ b/tester/covoar/covoar.cc
>> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPrefix.empty()) {
>>buildPrefix = *pri;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPrefix != *pri) {
>>  fail = "executable build prefix does not match: " +
>> buildPrefix;
>>  break;
>>}
>> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPath.empty()) {
>>buildPath = thisBuildPath;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPath != thisBuildPath) {
>>  fail = "executable build path does not match: " + buildPath;
>>}
>>  }
>> @@ -316,11 +316,7 @@ int main(
>>  std::cerr << "warning: Unable to read executable: " << argv[i]
>> << std::endl;
>>} else {
>>  coverageFileName = argv[i];
>> -coverageFileName.replace(
>> -  coverageFileName.length() - executableExtension.size(),
>> -  executableExtension.size(),
>> -  coverageExtension
>> -);
>> +coverageFileName.append( "." + coverageExtension );
>>
>>  if (!FileIsReadable( coverageFileName.c_str() )) {
>>std::cerr << "warning: Unable to read coverage file: " <<
>> coverageFileName
>> --
>> 2.7.4
>>
>> This worked !
>

Cool, looks like we're onto fixing the reports then. If you take a look at
report.html only the headings are there. I think what might be wrong there
is it's just searching in the wrong place for the results. The fix for that
will lie in coverage.py. Warning about coverage.py, there could be whole
sections in there that might just be deleted, it's still being reorganized.

Or seeing as covoar is in good shape now and I think the txt report is ok
(you should check and make sure of that). You could move onto gcov, lcov
stuff. Figure out the state of the gcov support in covoar, generate gcov
reports, compare the results.

> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 14 May 2018, 16:46 Joel Sherrill,  wrote:

> I'll commit this once there is a log message. :)
>

You want the word 'Fix' is it?... :)

>
> On Sun, May 13, 2018 at 3:45 PM, Cillian O'Donnell 
> wrote:
>
>> ---
>>  tester/covoar/covoar.cc | 10 +++---
>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>
>> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
>> index 5c87402..c6b0589 100644
>> --- a/tester/covoar/covoar.cc
>> +++ b/tester/covoar/covoar.cc
>> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPrefix.empty()) {
>>buildPrefix = *pri;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPrefix != *pri) {
>>  fail = "executable build prefix does not match: " +
>> buildPrefix;
>>  break;
>>}
>> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
>> executablesToAnalyze,
>>  if (buildPath.empty()) {
>>buildPath = thisBuildPath;
>>  } else {
>> -  if (buildBSP != *pri) {
>> +  if (buildPath != thisBuildPath) {
>>  fail = "executable build path does not match: " + buildPath;
>>}
>>  }
>> @@ -316,11 +316,7 @@ int main(
>>  std::cerr << "warning: Unable to read executable: " << argv[i]
>> << std::endl;
>>} else {
>>  coverageFileName = argv[i];
>> -coverageFileName.replace(
>> -  coverageFileName.length() - executableExtension.size(),
>> -  executableExtension.size(),
>> -  coverageExtension
>> -);
>> +coverageFileName.append( "." + coverageExtension );
>>
>>  if (!FileIsReadable( coverageFileName.c_str() )) {
>>std::cerr << "warning: Unable to read coverage file: " <<
>> coverageFileName
>> --
>> 2.7.4
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 14 May 2018, 09:50 Vijay Kumar Banerjee, 
wrote:

> On 14 May 2018 at 12:10, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sun, 13 May 2018, 22:15 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 14 May 2018 at 02:15, Cillian O'Donnell 
>>> wrote:
>>>
>>>> ---
>>>>  tester/covoar/covoar.cc | 10 +++---
>>>>  1 file changed, 3 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
>>>> index 5c87402..c6b0589 100644
>>>> --- a/tester/covoar/covoar.cc
>>>> +++ b/tester/covoar/covoar.cc
>>>> @@ -75,7 +75,7 @@ static void createBuildPath(Executables&
>>>> executablesToAnalyze,
>>>>  if (buildPrefix.empty()) {
>>>>buildPrefix = *pri;
>>>>  } else {
>>>> -  if (buildBSP != *pri) {
>>>> +  if (buildPrefix != *pri) {
>>>>  fail = "executable build prefix does not match: " +
>>>> buildPrefix;
>>>>  break;
>>>>}
>>>> @@ -97,7 +97,7 @@ static void createBuildPath(Executables&
>>>> executablesToAnalyze,
>>>>  if (buildPath.empty()) {
>>>>buildPath = thisBuildPath;
>>>>  } else {
>>>> -  if (buildBSP != *pri) {
>>>> +  if (buildPath != thisBuildPath) {
>>>>  fail = "executable build path does not match: " +
>>>> buildPath;
>>>>}
>>>>  }
>>>> @@ -316,11 +316,7 @@ int main(
>>>>  std::cerr << "warning: Unable to read executable: " << argv[i]
>>>> << std::endl;
>>>>} else {
>>>>  coverageFileName = argv[i];
>>>> -coverageFileName.replace(
>>>> -  coverageFileName.length() - executableExtension.size(),
>>>> -  executableExtension.size(),
>>>> -  coverageExtension
>>>> -);
>>>> +coverageFileName.append( "." + coverageExtension );
>>>>
>>>>  if (!FileIsReadable( coverageFileName.c_str() )) {
>>>>std::cerr << "warning: Unable to read coverage file: " <<
>>>> coverageFileName
>>>> --
>>>> 2.7.4
>>>>
>>>> This worked !
>>>
>>
>> Cool, looks like we're onto fixing the reports then. If you take a look
>> at report.html only the headings are there. I think what might be wrong
>> there is it's just searching in the wrong place for the results. The fix
>> for that will lie in coverage.py. Warning about coverage.py, there could be
>> whole sections in there that might just be deleted, it's still being
>> reorganized.
>>
>> Are you working on it ?
>

Yeah I'll be hacking away at that, won't make much of a dent till the
weekend though.

> Also the absolute path needs to be parsed form the score-symbol.ini for
> running it from out of the build tree
>

This is true.

> Or seeing as covoar is in good shape now and I think the txt report is ok
>> (you should check and make sure of that). You could move onto gcov, lcov
>> stuff. Figure out the state of the gcov support in covoar, generate gcov
>> reports, compare the results.
>>
> I'll creat a new thread for gcov report then.
>

Cool, you're gonna do the gcov stuff then.

> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>
>>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] covoar: Fix build path checks for multiple executables.

[Cillian O'Donnell]

---
 tester/covoar/covoar.cc | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/tester/covoar/covoar.cc b/tester/covoar/covoar.cc
index 5c87402..c6b0589 100644
--- a/tester/covoar/covoar.cc
+++ b/tester/covoar/covoar.cc
@@ -75,7 +75,7 @@ static void createBuildPath(Executables& executablesToAnalyze,
 if (buildPrefix.empty()) {
   buildPrefix = *pri;
 } else {
-  if (buildBSP != *pri) {
+  if (buildPrefix != *pri) {
 fail = "executable build prefix does not match: " + buildPrefix;
 break;
   }
@@ -97,7 +97,7 @@ static void createBuildPath(Executables& executablesToAnalyze,
 if (buildPath.empty()) {
   buildPath = thisBuildPath;
 } else {
-  if (buildBSP != *pri) {
+  if (buildPath != thisBuildPath) {
 fail = "executable build path does not match: " + buildPath;
   }
 }
@@ -316,11 +316,7 @@ int main(
 std::cerr << "warning: Unable to read executable: " << argv[i] << 
std::endl;
   } else {
 coverageFileName = argv[i];
-coverageFileName.replace(
-  coverageFileName.length() - executableExtension.size(),
-  executableExtension.size(),
-  coverageExtension
-);
+coverageFileName.append( "." + coverageExtension );
 
 if (!FileIsReadable( coverageFileName.c_str() )) {
   std::cerr << "warning: Unable to read coverage file: " << 
coverageFileName
-- 
2.7.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Thu, 17 May 2018, 21:32 Vijay Kumar Banerjee, 
wrote:

> hello,
>
> I have attached the html report !
>

Report looks good! Well done. Was that just for samples. Did the other
sections appear in the report if you click through the links?

Well it looks good but I hardcoded the paths, at least that gave the proper
> idea of what exactly needs to be done. Now I understand why
> --rtems-builddir stayed there for a long time , it makes the job simple .
>
> Here's a point that needs discussion :
>
> 1. the coverage.py in it's current state(before the updates I made today)
> tries to parse the score-symbols.ini file (class symbols_configuration()) ,
> which is not needed after the recent updates to covoar which makes it work
> from covoar itself. I have just removed that class for now .
>

Yeah there could definitely be some sections that might be completely
removed now. I left most things in because there's still some things
undecided. I'm not sure how we'll handle multiple sets now. Will we have
all sets in one .ini and create a new .ini for every different collection
of sets. Or will we define each set in one .ini each and pass multiple
.ini's to covoar. How will the user pick which sets he's interested in?
Pass names to coverage argument maybe

--coverage=score,core..etc

Chris when you redefined the config logic, how did imagine multiple sets
working?

>
> One thing can be done, which I think will solve parsing of the absolute
> path of the library as well. It is to implement the the logic that Chris
> used in covoar.cc , into the python script for coverage . Then we can do an
> os.path.abspath() for the absolute path and the extract the directory name
> from there for the html report from the same place. Can we do it that way ?
>

Sounds like a good plan. Definitely give it a shot.

>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Fri, 18 May 2018, 07:46 Vijay Kumar Banerjee, 
wrote:

> On Fri, 18 May 2018, 11:52 Cillian O'Donnell, 
> wrote:
>
>>
>>
>> On Thu, 17 May 2018, 21:32 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> hello,
>>>
>>> I have attached the html report !
>>>
>>
>> Report looks good! Well done. Was that just for samples. Did the other
>> sections appear in the report if you click through the links?
>>
> yes it was for samples and yes the links are working
>

Cool, you should run it for the full testsuite and take a look at that
report (takes a while.. around 575 tests)

>
>> Well it looks good but I hardcoded the paths, at least that gave the
>>> proper idea of what exactly needs to be done. Now I understand why
>>> --rtems-builddir stayed there for a long time , it makes the job simple .
>>>
>>> Here's a point that needs discussion :
>>>
>>> 1. the coverage.py in it's current state(before the updates I made
>>> today) tries to parse the score-symbols.ini file (class
>>> symbols_configuration()) , which is not needed after the recent updates to
>>> covoar which makes it work from covoar itself. I have just removed that
>>> class for now .
>>>
>>
>> Yeah there could definitely be some sections that might be completely
>> removed now. I left most things in because there's still some things
>> undecided. I'm not sure how we'll handle multiple sets now. Will we have
>> all sets in one .ini and create a new .ini for every different collection
>> of sets. Or will we define each set in one .ini each and pass multiple
>> .ini's to covoar. How will the user pick which sets he's interested in?
>> Pass names to coverage argument maybe
>>
>> --coverage=score,core..etc
>>
> The script used to treat it like a collection of sets. I was thinking of
> running a loop over all the keys under a tag [symbol-sets] and getting
> their respective libraries .
> Is it for the user to decide which sets to use?
>

It's probably best to give some options to change the sets under test.

> Do we need to have a separate ini file for each set?
>

It can work either way, it's more a matter of which is the better design.

>
>> Chris when you redefined the config logic, how did imagine multiple sets
>> working?
>>
>>>
>>> One thing can be done, which I think will solve parsing of the absolute
>>> path of the library as well. It is to implement the the logic that Chris
>>> used in covoar.cc , into the python script for coverage . Then we can do an
>>> os.path.abspath() for the absolute path and the extract the directory name
>>> from there for the html report from the same place. Can we do it that way ?
>>>
>>
>> Sounds like a good plan. Definitely give it a shot.
>>
> it would be good if it works out, but again , the main challenge is the
> path to build directory. :p
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, 
wrote:

>
> On 18 May 2018 at 12:30, Cillian O'Donnell  wrote:
>
>
>> Cool, you should run it for the full testsuite and take a look at that
>> report (takes a while.. around 575 tests)
>>
>>>
>>>> When I try to run the full testsuites it gives the following error .
> What could be causing this ?
>

If you run the full testsuite without the coverage options, does it still
happen?

>
>  ---
> self.__bootstrap_inner()
>   File "/usr/lib64/python2.7/threading.py", line 817, in __bootstrap_inner
> (self.name, _format_exc()))
> IOError: [Errno 11] Resource temporarily unavailable
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, 
wrote:

>
>
> On 18 May 2018 at 19:09, Cillian O'Donnell  wrote:
>
>>
>>
>> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>> On 18 May 2018 at 12:30, Cillian O'Donnell 
>>> wrote:
>>>
>>>
>>>> Cool, you should run it for the full testsuite and take a look at that
>>>> report (takes a while.. around 575 tests)
>>>>
>>>>>
>>>>>> When I try to run the full testsuites it gives the following error .
>>> What could be causing this ?
>>>
>>
>> If you run the full testsuite without the coverage options, does it still
>> happen?
>>
> No it seems to run fine without coverage.
>

I vaguely remember seeing this before last year, I suspect that when things
are cleared up in coverage.py it will dissappear. So don't worry about it
for now, carry on with what you're doing. What branch are you working on at
the moment?

>
>>>  ---
>>> self.__bootstrap_inner()
>>>   File "/usr/lib64/python2.7/threading.py", line 817, in
>>> __bootstrap_inner
>>> (self.name, _format_exc()))
>>> IOError: [Errno 11] Resource temporarily unavailable
>>>
>>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On 18 May 2018 at 23:24, Vijay Kumar Banerjee 
wrote:

> On 19 May 2018 at 03:29, Joel Sherrill  wrote:
>
>>
>>
>> On Fri, May 18, 2018 at 4:53 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, 19 May 2018, 03:06 Joel Sherrill,  wrote:
>>>
>>>>
>>>>
>>>> On Fri, May 18, 2018 at 4:01 PM, Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> On 19 May 2018 at 02:29, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> On 19 May 2018 at 01:30, Cillian O'Donnell 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, <
>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 18 May 2018 at 19:09, Cillian O'Donnell 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
>>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 18 May 2018 at 12:30, Cillian O'Donnell >>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Cool, you should run it for the full testsuite and take a look
>>>>>>>>>>> at that report (takes a while.. around 575 tests)
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> When I try to run the full testsuites it gives the following
>>>>>>>>>> error . What could be causing this ?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If you run the full testsuite without the coverage options, does
>>>>>>>>> it still happen?
>>>>>>>>>
>>>>>>>> No it seems to run fine without coverage.
>>>>>>>>
>>>>>>>
>>>>>>> I vaguely remember seeing this before last year, I suspect that when
>>>>>>> things are cleared up in coverage.py it will dissappear. So don't worry
>>>>>>> about it for now, carry on with what you're doing. What branch are you
>>>>>>> working on at the moment?
>>>>>>>
>>>>>> The path to build directory from the executable path is working now !
>>>>>>
>>>>>> I'm working in this branch currently, I'll send a patch to all of it
>>>>>> together when it starts working.
>>>>>>
>>>>> I meant to say once the parsing of ini file starts working. the path
>>>>> to build directory is already working.
>>>>>
>>>>>> Please have a look and also suggest improvements where applicable .
>>>>>>
>>>>>> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support.
>>>>>>
>>>>>> after this update, running it on full testsuits doesn't give that
>>>>>> error anymore but it has some other issue. The report doesn't shows data
>>>>>> only for samples even after running it for full testsuites
>>>>>>
>>>>>
>>>> Do you have coverage output on all the tests?
>>>>
>>> I have coverage output on tests under samples/ only .
>>> running it for the whole testsuits gives the same coverage output as
>>> with samples/
>>>
>>>>
>>>> Is the verbose output indicating that all the tests are being looped
>>>> over?
>>>>
>>>>
>>>>>
>>>>>> and I'm getting this error :
>>>>>>
>>>>>> -
>>>>>> ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
>>>>>>
>>>>>
>>>>
>>>> Cillian must want to purge all memory of this type of message. :)
>>>>
>>>> This message indi

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, 
wrote:

> On 19 May 2018 at 16:47, Cillian O'Donnell  wrote:
>
>>
>> God these messages again... at least I'm an expert in fixing these :)
>> Vijay I'm only seeing the headings in the report on my end using your
>> branch. How are you running it and from where? Is there any changes you
>> haven't pushed?
>>
> I'm rurrning it from top of build tree, the latest change I pushed was
> yesterday
> <https://github.com/thelunatic/rtems-tools/commit/8b4d90821c2af3dc37282c06722cd3eadb5223f4>
>  and
> I haven't made any changes after that. the report seems to be running here.
>

Strange.. if you clean everything away that covoar outputs and run it
again, can it still find the data?

>
>> Coverage run for score finished successfully.
>>> ---
>>>
>>>
>>>> --joel
>>>>
>>>>
>>>>>
>>>>>> --joel
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> devel mailing list
>>>>>>> devel@rtems.org
>>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sat, 19 May 2018, 13:28 Vijay Kumar Banerjee, 
wrote:

> On 19 May 2018 at 17:56, Vijay Kumar Banerjee 
> wrote:
>
>> On 19 May 2018 at 17:50, Vijay Kumar Banerjee 
>> wrote:
>>
>>> On 19 May 2018 at 17:44, Cillian O'Donnell 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> On 19 May 2018 at 16:47, Cillian O'Donnell 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> God these messages again... at least I'm an expert in fixing these :)
>>>>>> Vijay I'm only seeing the headings in the report on my end using your
>>>>>> branch. How are you running it and from where? Is there any changes you
>>>>>> haven't pushed?
>>>>>>
>>>>> I'm rurrning it from top of build tree, the latest change I pushed was
>>>>> yesterday
>>>>> <https://github.com/thelunatic/rtems-tools/commit/8b4d90821c2af3dc37282c06722cd3eadb5223f4>
>>>>>  and
>>>>> I haven't made any changes after that. the report seems to be running 
>>>>> here.
>>>>>
>>>>
>>>> Strange.. if you clean everything away that covoar outputs and run it
>>>> again, can it still find the data?
>>>>
>>> please see the attached image.
>>> It seems to be working pretty fine.
>>>
>>> Can you please try cleaning out everything, fetching my
>> cov-tester-support branch, ./waf build install it and then try running
>> tester form the top of the build tree?
>>
> please run it for samples only, running it for whole testsuites is not
> generating proper report currently.
>

Yeah I'll give it another try when I get home. At the beach at the moment.

>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

It works.. Sorry I was using the right covoar but the wrong rtems-test. Ahh
its nice to see the data back in the reports again. Did you manage to track
down 2 exes with the mismatch in symbol size?

On 19 May 2018 at 13:59, Vijay Kumar Banerjee 
wrote:

> On 19 May 2018 at 18:28, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sat, 19 May 2018, 13:28 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 19 May 2018 at 17:56, Vijay Kumar Banerjee 
>>> wrote:
>>>
>>>> On 19 May 2018 at 17:50, Vijay Kumar Banerjee >>> > wrote:
>>>>
>>>>> On 19 May 2018 at 17:44, Cillian O'Donnell 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> On 19 May 2018 at 16:47, Cillian O'Donnell 
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> God these messages again... at least I'm an expert in fixing these
>>>>>>>> :) Vijay I'm only seeing the headings in the report on my end using 
>>>>>>>> your
>>>>>>>> branch. How are you running it and from where? Is there any changes you
>>>>>>>> haven't pushed?
>>>>>>>>
>>>>>>> I'm rurrning it from top of build tree, the latest change I pushed
>>>>>>> was yesterday
>>>>>>> <https://github.com/thelunatic/rtems-tools/commit/8b4d90821c2af3dc37282c06722cd3eadb5223f4>
>>>>>>>  and
>>>>>>> I haven't made any changes after that. the report seems to be running 
>>>>>>> here.
>>>>>>>
>>>>>>
>>>>>> Strange.. if you clean everything away that covoar outputs and run it
>>>>>> again, can it still find the data?
>>>>>>
>>>>> please see the attached image.
>>>>> It seems to be working pretty fine.
>>>>>
>>>>> Can you please try cleaning out everything, fetching my
>>>> cov-tester-support branch, ./waf build install it and then try running
>>>> tester form the top of the build tree?
>>>>
>>> please run it for samples only, running it for whole testsuites is not
>>> generating proper report currently.
>>>
>>
>> Yeah I'll give it another try when I get home. At the beach at the moment.
>>
> sure , enjoy !
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC coverage] Possibility of being less active due to exams.

[Cillian O'Donnell]

On Sat, 19 May 2018, 20:59 Vijay Kumar Banerjee, 
wrote:

> Hello,
>
> My end sem exams are starting next week from 22nd May and will go till
> 31st May. During this period I will be less efficient.
> I understand that the project is in a crucial state and 10 days of
> inactivity is unacceptable so I will try my best to be as active as
> possible during the gaps between the exam and keep working on the project
> and the blog. I hope this is fine.
>

Yes that's fine, focus on your exams and do what you can. All the best, I
hope they well for you Vijay. Good luck!

>
>
> sincerely,
> vijay
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, 
wrote:

> On 20 May 2018 at 00:53, Vijay Kumar Banerjee 
> wrote:
>
>>
>>
>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
>> wrote:
>>
>>> It works.. Sorry I was using the right covoar but the wrong rtems-test.
>>> Ahh its nice to see the data back in the reports again. Did you manage to
>>> track down 2 exes with the mismatch in symbol size?
>>>
>> Great! so next is the parsing of the symbol file.
>> I couldn't manage to track down the mismatch.
>>
>> I have pushed these to my master branch.
>
> The latest update to cov-tester-support branch (please have a look)
> parses the symbol-set ini file from the coverage script. The parsing
> is working but currently it's not generating reports, as covoar
> needs to be updated .
>

It's best if covoar reads it's own config file, otherwise it creates a
dependency on the tester. Scanning over the recent changes to covoar there,
it looks like it can already handle multiple sets, so the one ini with
multiple sets in it is the way to go.

> Here are the things that I have done and that needs to be
> done in order to generate reports :
>
> I have added a symbol-sets.ini file and parsed it from the coverage script
> this is how it works :
>
>
>- The ini file can be updated with all the symbols, separated by ' , '
>(comma)
>
>
This is the way covoar is actually handling it now. You should test a multi
set ini and see if that's working.

>
>-
>- The coverages splits them and makes a list of all the sets
>-  The respective libraries are parsed from the libraries section.
>- It returns a dict with all the symbols and thir resp. library
>addresses.
>- The library addresses are absolute so it can be run from anywhere
>top of build tree is not necessary.
>
> This was a good idea but it's just that dependency issue we want to stay
away from. Covoar has something to find the build directory too, it just
hasn't been connected up yet, so running it from the top of the build
directory is ok for the moment.

Probably the most pressing thing now is investigating those mismatch in
symbol size.

> This way we can parse all the symbols from the same ini file.
>
> what needs to be done :
>
>- I have added #FIXME s in the code , those are the small fixes that
>would be needed .
>- The covoar needs to be updated. My proposal is that we can feed the
>parsed  dict to the covoar instead of feeding the symbol file and
>letting
>covoar parse it ( As I mentioned previously).
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, 
wrote:

> On 21 May 2018 at 02:29, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
>>>> wrote:
>>>>
>>>>> It works.. Sorry I was using the right covoar but the wrong
>>>>> rtems-test. Ahh its nice to see the data back in the reports again. Did 
>>>>> you
>>>>> manage to track down 2 exes with the mismatch in symbol size?
>>>>>
>>>> Great! so next is the parsing of the symbol file.
>>>> I couldn't manage to track down the mismatch.
>>>>
>>>> I have pushed these to my master branch.
>>>
>>> The latest update to cov-tester-support branch (please have a look)
>>> parses the symbol-set ini file from the coverage script. The parsing
>>> is working but currently it's not generating reports, as covoar
>>> needs to be updated .
>>>
>>
>> It's best if covoar reads it's own config file, otherwise it creates a
>> dependency on the tester. Scanning over the recent changes to covoar there,
>> it looks like it can already handle multiple sets, so the one ini with
>> multiple sets in it is the way to go.
>>
> Okay, Understood.
>
>> Here are the things that I have done and that needs to be
>>> done in order to generate reports :
>>>
>>> I have added a symbol-sets.ini file and parsed it from the coverage
>>> script
>>> this is how it works :
>>>
>>>
>>>- The ini file can be updated with all the symbols, separated by ' ,
>>>' (comma)
>>>
>>>
>> This is the way covoar is actually handling it now. You should test a
>> multi set ini and see if that's working.
>>
> Yeah, I have seen it. will try with multiple sets.
>
>>
>>>-
>>>- The coverages splits them and makes a list of all the sets
>>>-  The respective libraries are parsed from the libraries section.
>>>- It returns a dict with all the symbols and thir resp. library
>>>addresses.
>>>- The library addresses are absolute so it can be run from anywhere
>>>top of build tree is not necessary.
>>>
>>> This was a good idea but it's just that dependency issue we want to stay
>> away from. Covoar has something to find the build directory too, it just
>> hasn't been connected up yet, so running it from the top of the build
>> directory is ok for the moment.
>>
>
> yes it can find the build directory. I was giving it a shot to do it from
> the script.
>
> If covoar's standalone working is a necessity then it surely needs to be
> working
> from covoar and shouldn't depend on the script.
>

It should be working from covoar and it will.

>
>> Probably the most pressing thing now is investigating those mismatch in
>> symbol size.
>>
>
> any advice on where/how to look for it ?
>

Before what I was doing was examining the objdump of 2 exes, looking there
on the weekend i think the info messages mentioned which ones were having
trouble for which symbol. It says something like "couldn't merge coverage
map for some_symbol because sizes from exe != to size of other_exe. Look at
the objdump of exe and other_exe, search for some_symbol and compare the
dissasembly. There'll be more lines in one than the other, nop padding
probably. Then you had to find a check that was strict enough to chop the
end of the symbol in question at the right place but not so strict that it
chopped other symbols in the wrong place. However the method of obtaining
the symbols has changed, I'll have to have a look over the covoar changes
tonight to see what would be the equivalent method of checking this now.
Unless Chris or Joel come back with the answer before then.

Also there will probably be multiple ini's with different collections of
sets that the user could run so it would be good to give them some method
of choosing which ini they want, like coverage=score will feed score.ini to
covoar. You could try have a go at that.

> This way we can parse all the symbols from the same ini file.
>>>
>>> what needs to be done :
>>>
>>>- I have added #FIXME s in the code , those are the small fixes that
>>>would be needed .
>>>- The covoar needs to be updated. My proposal is that we can feed the
>>>parsed  dict to the covoar instead of feeding the symbol file and
>>>letting
>>>covoar parse it ( As I mentioned previously).
>>>
>>>
>>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, 
wrote:

> On 21 May 2018 at 11:56, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 21 May 2018 at 02:29, Cillian O'Donnell 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
>>>>>> wrote:
>>>>>>
>>>>>>> It works.. Sorry I was using the right covoar but the wrong
>>>>>>> rtems-test. Ahh its nice to see the data back in the reports again. Did 
>>>>>>> you
>>>>>>> manage to track down 2 exes with the mismatch in symbol size?
>>>>>>>
>>>>>> Great! so next is the parsing of the symbol file.
>>>>>> I couldn't manage to track down the mismatch.
>>>>>>
>>>>>> I have pushed these to my master branch.
>>>>>
>>>>> The latest update to cov-tester-support branch (please have a look)
>>>>> parses the symbol-set ini file from the coverage script. The parsing
>>>>> is working but currently it's not generating reports, as covoar
>>>>> needs to be updated .
>>>>>
>>>>
>>>> It's best if covoar reads it's own config file, otherwise it creates a
>>>> dependency on the tester. Scanning over the recent changes to covoar there,
>>>> it looks like it can already handle multiple sets, so the one ini with
>>>> multiple sets in it is the way to go.
>>>>
>>> Okay, Understood.
>>>
>>>> Here are the things that I have done and that needs to be
>>>>> done in order to generate reports :
>>>>>
>>>>> I have added a symbol-sets.ini file and parsed it from the coverage
>>>>> script
>>>>> this is how it works :
>>>>>
>>>>>
>>>>>- The ini file can be updated with all the symbols, separated by '
>>>>>, ' (comma)
>>>>>
>>>>>
>>>> This is the way covoar is actually handling it now. You should test a
>>>> multi set ini and see if that's working.
>>>>
>>> Yeah, I have seen it. will try with multiple sets.
>>>
>>>>
>>>>>-
>>>>>- The coverages splits them and makes a list of all the sets
>>>>>-  The respective libraries are parsed from the libraries section.
>>>>>- It returns a dict with all the symbols and thir resp. library
>>>>>addresses.
>>>>>- The library addresses are absolute so it can be run from anywhere
>>>>>top of build tree is not necessary.
>>>>>
>>>>> This was a good idea but it's just that dependency issue we want to
>>>> stay away from. Covoar has something to find the build directory too, it
>>>> just hasn't been connected up yet, so running it from the top of the build
>>>> directory is ok for the moment.
>>>>
>>>
>>> yes it can find the build directory. I was giving it a shot to do it
>>> from the script.
>>>
>>> If covoar's standalone working is a necessity then it surely needs to be
>>> working
>>> from covoar and shouldn't depend on the script.
>>>
>>
>> It should be working from covoar and it will.
>>
>>>
>>>> Probably the most pressing thing now is investigating those mismatch in
>>>> symbol size.
>>>>
>>>
>>> any advice on where/how to look for it ?
>>>
>>
>> Before what I was doing was examining the objdump of 2 exes, looking
>> there on the weekend i think the info messages mentioned which ones were
>> having trouble for which symbol. It says something like "couldn't merge
>> coverage map for some_symbol because sizes from exe != to size of
>> other_exe. Look at the objdump of exe and other_exe, search for some_symbol
>> and compare the dissasembly. There'll be more lines in one than the other,

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 21 May 2018, 12:08 Cillian O'Donnell,  wrote:

>
>
> On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, 
> wrote:
>
>> On 21 May 2018 at 11:56, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> On 21 May 2018 at 02:29, Cillian O'Donnell 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> It works.. Sorry I was using the right covoar but the wrong
>>>>>>>> rtems-test. Ahh its nice to see the data back in the reports again. 
>>>>>>>> Did you
>>>>>>>> manage to track down 2 exes with the mismatch in symbol size?
>>>>>>>>
>>>>>>> Great! so next is the parsing of the symbol file.
>>>>>>> I couldn't manage to track down the mismatch.
>>>>>>>
>>>>>>> I have pushed these to my master branch.
>>>>>>
>>>>>> The latest update to cov-tester-support branch (please have a look)
>>>>>> parses the symbol-set ini file from the coverage script. The parsing
>>>>>> is working but currently it's not generating reports, as covoar
>>>>>> needs to be updated .
>>>>>>
>>>>>
>>>>> It's best if covoar reads it's own config file, otherwise it creates a
>>>>> dependency on the tester. Scanning over the recent changes to covoar 
>>>>> there,
>>>>> it looks like it can already handle multiple sets, so the one ini with
>>>>> multiple sets in it is the way to go.
>>>>>
>>>> Okay, Understood.
>>>>
>>>>> Here are the things that I have done and that needs to be
>>>>>> done in order to generate reports :
>>>>>>
>>>>>> I have added a symbol-sets.ini file and parsed it from the coverage
>>>>>> script
>>>>>> this is how it works :
>>>>>>
>>>>>>
>>>>>>- The ini file can be updated with all the symbols, separated by
>>>>>>' , ' (comma)
>>>>>>
>>>>>>
>>>>> This is the way covoar is actually handling it now. You should test a
>>>>> multi set ini and see if that's working.
>>>>>
>>>> Yeah, I have seen it. will try with multiple sets.
>>>>
>>>>>
>>>>>>-
>>>>>>- The coverages splits them and makes a list of all the sets
>>>>>>-  The respective libraries are parsed from the libraries section.
>>>>>>- It returns a dict with all the symbols and thir resp. library
>>>>>>addresses.
>>>>>>- The library addresses are absolute so it can be run from
>>>>>>anywhere
>>>>>>top of build tree is not necessary.
>>>>>>
>>>>>> This was a good idea but it's just that dependency issue we want to
>>>>> stay away from. Covoar has something to find the build directory too, it
>>>>> just hasn't been connected up yet, so running it from the top of the build
>>>>> directory is ok for the moment.
>>>>>
>>>>
>>>> yes it can find the build directory. I was giving it a shot to do it
>>>> from the script.
>>>>
>>>> If covoar's standalone working is a necessity then it surely needs to
>>>> be working
>>>> from covoar and shouldn't depend on the script.
>>>>
>>>
>>> It should be working from covoar and it will.
>>>
>>>>
>>>>> Probably the most pressing thing now is investigating those mismatch
>>>>> in symbol size.
>>>>>
>>>>
>>>> any advice on where/how to look for it ?
>>>

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Mon, 21 May 2018, 12:18 Vijay Kumar Banerjee, 
wrote:

> On 21 May 2018 at 16:39, Cillian O'Donnell  wrote:
>
>>
>>
>> On Mon, 21 May 2018, 12:08 Cillian O'Donnell, 
>> wrote:
>>
>>>
>>>
>>> On Mon, 21 May 2018, 11:49 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
>>>> On 21 May 2018 at 11:56, Cillian O'Donnell 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sun, 20 May 2018, 22:33 Vijay Kumar Banerjee, <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> On 21 May 2018 at 02:29, Cillian O'Donnell 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, 20 May 2018, 15:35 Vijay Kumar Banerjee, <
>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 20 May 2018 at 00:53, Vijay Kumar Banerjee <
>>>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sun, 20 May 2018, 00:45 Cillian O'Donnell, <
>>>>>>>>> cpodonne...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> It works.. Sorry I was using the right covoar but the wrong
>>>>>>>>>> rtems-test. Ahh its nice to see the data back in the reports again. 
>>>>>>>>>> Did you
>>>>>>>>>> manage to track down 2 exes with the mismatch in symbol size?
>>>>>>>>>>
>>>>>>>>> Great! so next is the parsing of the symbol file.
>>>>>>>>> I couldn't manage to track down the mismatch.
>>>>>>>>>
>>>>>>>>> I have pushed these to my master branch.
>>>>>>>>
>>>>>>>> The latest update to cov-tester-support branch (please have a look)
>>>>>>>> parses the symbol-set ini file from the coverage script. The
>>>>>>>> parsing
>>>>>>>> is working but currently it's not generating reports, as covoar
>>>>>>>> needs to be updated .
>>>>>>>>
>>>>>>>
>>>>>>> It's best if covoar reads it's own config file, otherwise it creates
>>>>>>> a dependency on the tester. Scanning over the recent changes to covoar
>>>>>>> there, it looks like it can already handle multiple sets, so the one ini
>>>>>>> with multiple sets in it is the way to go.
>>>>>>>
>>>>>> Okay, Understood.
>>>>>>
>>>>>>> Here are the things that I have done and that needs to be
>>>>>>>> done in order to generate reports :
>>>>>>>>
>>>>>>>> I have added a symbol-sets.ini file and parsed it from the coverage
>>>>>>>> script
>>>>>>>> this is how it works :
>>>>>>>>
>>>>>>>>
>>>>>>>>- The ini file can be updated with all the symbols, separated
>>>>>>>>by ' , ' (comma)
>>>>>>>>
>>>>>>>>
>>>>>>> This is the way covoar is actually handling it now. You should test
>>>>>>> a multi set ini and see if that's working.
>>>>>>>
>>>>>> Yeah, I have seen it. will try with multiple sets.
>>>>>>
>>>>>>>
>>>>>>>>-
>>>>>>>>- The coverages splits them and makes a list of all the sets
>>>>>>>>-  The respective libraries are parsed from the libraries
>>>>>>>>section.
>>>>>>>>- It returns a dict with all the symbols and thir resp. library
>>>>>>>>addresses.
>>>>>>>>- The library addresses are absolute so it can be run from
>>>>>>>>anywhere
>>>>>>>>top of build tree is not necessary.
>>>>>>>>
>>>>>>>> This was a good idea but it's just that dependency issue we want to
>>>>>>> s

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

>>> it looks the same though.
>>>
>>
>> Are you sure those are the two executables which it is tripping over?
>>
> they were the first two in the list . seems like there are other exes
> having conflict with base_sp in other symbols.
>
> have a look
> =
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for _Workspace_Allocate_or_fatal_error with different sizes
> (/home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/capture/capture.exe/84 !=
> /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/60)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for hex2ascii_data with different sizes
> (/home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/capture/capture.exe/41 !=
> /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/49)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for _Thread_queue_Operations_default with different sizes
> (/home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/capture/capture.exe/356 !=
> /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/352)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for CSWTCH.1 with different sizes (/home/lunatic/development/
> rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture/capture.exe/32
> != /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/756)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for _Workspace_Allocate_or_fatal_error with different sizes
> (/home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/cdtest/cdtest.exe/84 !=
> /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/80)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for CSWTCH.1 with different sizes (/home/lunatic/development/
> rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/cdtest/cdtest.exe/756
> != /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/12)
> INFO: DesiredSymbols::createCoverageMap - Attempt to create unified
> coverage maps for _Workspace_Allocate_or_fatal_error with different sizes
> (/home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/fileio/fileio.exe/84 !=
> /home/lunatic/development/rtems/kernel/leon3/sparc-
> rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe/60)
> =
>
>
>> I have never seen a case where the code matched by hand and covoar messed
>> up. But there is always the first. :)
>>
>> I can look into it in more detail with some instructions as I'm clueless
> myself.
>
>
>> Are you running with just those two executables?
>>
>> I'm running with all the samples/
>
>> If the input Is the same and covoar doesn't believe it, then gdb is your
>> friend. Or you will have to add some helpful verbose messages that Cillian
>> and I couldn't.
>>
>> I don't yet understand it clearly. It surely needs some more messages.
>
> Is it only me with these messages ?
>
>>
>>
>>>>> base_sp: 0x48 - 0x0c = 0x3C ==> 60
>>>>>> capture: 0x78 - 0x3c = 0x3c ==> 60
>>>>>>
>>>>>> Based on that alone, they are the same size. Now let's look at the
>>>>>> objdump and see what's
>>>>>> at the end that might look like padding:
>>>>>>
>>>>>> base_sp.exe 
>>>>>> _Internal_error( INTERNAL_ERROR_WORKSPACE_ALLOCATION );
>>>>>>  200ba3c:   7f ff ea d4 call  200658c <_Internal_error>
>>>>>>  200ba40:   90 10 20 03 mov  3, %o0
>>>>>>  200ba44:   01 00 00 00 nop
>>>>>> 
>>>>>>
>>>>>> The nop would be considered padding by covoar since it is at the end
>>>>>> of the method.
>>>>>>
>>>>>> capture.exe ===
>>>>>>
>>>>>> _Internal_error( INTERNAL_ERROR_WORKSPAC

Re: [PATCH] covoar.cc: Correct build path checks for multiple executables.

[Cillian O'Donnell]

On Sun, 27 May 2018, 19:59 Vijay Kumar Banerjee, 
wrote:

> Hello,
>
> The support for letting users input specific symbols
> for coverage analysis is now working in my
> cov-tester-support branch
>
> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support
>

Brilliant Vijay, I'll take a look today or tomorrow.

>
>
> Please have a look into the code and test it.
>
> The user can input specific symbols with the --coverage
> option to run covoar on specific symbols
>
> example :-
>
> --coverage=symbol1,symbol2,symbol3
>
> if no argument is provided then coverage will run for
> all the symbols given in the symbol-sets.ini file .
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Coverage support for tester

[Cillian O'Donnell]

On Wed, 30 May 2018, 16:58 Gedare Bloom,  wrote:

> On Wed, May 30, 2018 at 11:32 AM, Vijay Kumar Banerjee
>  wrote:
> > On 30 May 2018 at 20:18, Gedare Bloom  wrote:
> >>
> >> Hello Vijay,
> >>
> >> Do you expect/need an answer to something in here?
> >>
> >> gedare
> >>
> > Hello,
> >
> > I wanted to know if there were any plans on how covoar
> > should store the reports when running for multisets.
> > Earlier it used to be done by the coverage script,
> > after the recent changes covoar can process multi sets.
> >
> > I think, covoar should store the reports into separate directories
> > for each set . eg. score/ , rtems/ . As the coverage can already read
> > from separate directories.
>

Sorry I thought all questions had been answered here. I think you have the
right idea. Each set should be a sub-directory of coverage directory.

By the way I tested your changes and everything seems fine. Still have to
do a review of coverage.py to see how close we are to merging.

> >
> > Any advice on how should it be approached ?
>
> It would help me if you could draw/write a diagram of what the
> filesystem tree might look like with separate directories, and what
> will go in each subdirectory.
>
> I don't have enough context to give any useful advice on this question.
>
> -Gedare
>
> >>
> >> On Wed, May 30, 2018 at 10:29 AM, Vijay Kumar Banerjee
> >>  wrote:
> >> > On 30 May 2018 at 00:54, Joel Sherrill  wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Tue, May 29, 2018 at 11:27 AM, Vijay Kumar Banerjee
> >> >>  wrote:
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Tue, 29 May 2018, 20:10 Joel Sherrill,  wrote:
> >> 
> >> 
> >> 
> >>  On Mon, May 28, 2018 at 11:08 PM, Chris Johns 
> >>  wrote:
> >> >
> >> > On 29/5/18 4:26 am, Joel Sherrill wrote:
> >> > > On Mon, May 28, 2018 at 5:43 AM, Vijay Kumar Banerjee
> >> > >  >> > > > wrote:
> >> > >
> >> > > Hello,
> >> > >
> >> > > The coverage reports are now showing results.
> >> > > The current branch that holds all the changes is
> >> > > the cov-tester-support branch in my forked repo
> >> > >
> >> > >
> >> > >
> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support
> >> > >
> >> > >
> >> > > <
> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support>
> >> > >
> >> > > (Please have a look into the code and test it.)
> >> > >
> >> > > It is close to merging (hopefully). These are the issues
> >> > > that would need a fix before it can be merged :
> >> > >
> >> > > 1. I have added some #FIXME in the code (have a look)
> >> > > in coverage script. I have set the value of the targe to
> >> > > be
> >> > > sparc-rtems5, which makes it limited to sparc-rtems5
> only.
> >> > > We
> >> > > can
> >> > > include the target in the bsp ini file, That would
> >> > > be a quick fix for this.
> >> > >
> >> > >
> >> > > Yes. This needs to be fixed.
> >> > >
> >> > > My hack to add 4 in ObjdumpProcessor.cc needs to be addressed
> >> > > also.
> >> > > I am thinking of adding a method to Target_*.cc to ask for the
> >> > > size
> >> > > of an
> >> > > instruction.
> >> > > Then pass it the last instruction. That way we can throw on
> other
> >> > > architectures for
> >> > > now. If Chris solves this with his changes before we try another
> >> > > architecture,
> >> > > great.
> >> > > If not, it will be easy to fix.
> >> >
> >> > What is the overall requirement?
> >> 
> >> 
> >>  To know the ending address of the function.
> >> 
> >>  Technically there are three pieces of information:
> >> 
> >>  + start address
> >>  + end address
> >>  + size
> >> 
> >>  If you know two of those, you can compute the third.
> >> 
> >>  I don't care if this comes from DWARF, ELF, or parsing the
> >>  disassembly.
> >>  It just needs to be reliable.
> >> 
> >>  And.. I am not proposing my solution as permanent. Just to keep us
> >>  moving. You want to change to an internal disassembler (which
> >>  would also need to have the source interspersed) and DWARF. So
> >>  this code would go away then.
> >> 
> >> >
> >> >
> >> > What defines the function and so size are attempting to get
> coverage
> >> > of? What if
> >> > that function calls an inline function and that function is
> inlined?
> >> > What if
> >> > that inlined function calls another inlined function?
> >> 
> >> 
> >>  Then it is all inlined. It is done consistently now. I have never
> >>  seen a
> >>  case
> >>  where two instances of a method differed as the assembly level. [1]
> >> 
> >>  The actual body of the inlined method is evaluated at each
> expansion
> >>  point.
> >> 

Re: Coverage support for tester

[Cillian O'Donnell]

On Wed, 30 May 2018, 18:15 Vijay Kumar Banerjee, 
wrote:

>
>
> On Wed, 30 May 2018, 22:42 Cillian O'Donnell, 
> wrote:
>
>>
>>
>> On Wed, 30 May 2018, 16:58 Gedare Bloom,  wrote:
>>
>>> On Wed, May 30, 2018 at 11:32 AM, Vijay Kumar Banerjee
>>>  wrote:
>>> > On 30 May 2018 at 20:18, Gedare Bloom  wrote:
>>> >>
>>> >> Hello Vijay,
>>> >>
>>> >> Do you expect/need an answer to something in here?
>>> >>
>>> >> gedare
>>> >>
>>> > Hello,
>>> >
>>> > I wanted to know if there were any plans on how covoar
>>> > should store the reports when running for multisets.
>>> > Earlier it used to be done by the coverage script,
>>> > after the recent changes covoar can process multi sets.
>>> >
>>> > I think, covoar should store the reports into separate directories
>>> > for each set . eg. score/ , rtems/ . As the coverage can already read
>>> > from separate directories.
>>>
>>
>> Sorry I thought all questions had been answered here. I think you have
>> the right idea. Each set should be a sub-directory of coverage directory.
>>
>> By the way I tested your changes and everything seems fine. Still have to
>> do a review of coverage.py to see how close we are to merging.
>>
> I have squashed everything and sent a patch to devel@. This will make it
> easy to go through all the changes. Please have a look.
>

Ah just seen it, will take a look. It'll be good to get Chris' thoughts
too. We'll have something more definitive about how close it is to merging.

> >
>>> > Any advice on how should it be approached ?
>>>
>>> It would help me if you could draw/write a diagram of what the
>>> filesystem tree might look like with separate directories, and what
>>> will go in each subdirectory.
>>>
>>> I don't have enough context to give any useful advice on this question.
>>>
>>> -Gedare
>>>
>>> >>
>>> >> On Wed, May 30, 2018 at 10:29 AM, Vijay Kumar Banerjee
>>> >>  wrote:
>>> >> > On 30 May 2018 at 00:54, Joel Sherrill  wrote:
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Tue, May 29, 2018 at 11:27 AM, Vijay Kumar Banerjee
>>> >> >>  wrote:
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> On Tue, 29 May 2018, 20:10 Joel Sherrill,  wrote:
>>> >> >>>>
>>> >> >>>>
>>> >> >>>>
>>> >> >>>> On Mon, May 28, 2018 at 11:08 PM, Chris Johns 
>>> >> >>>> wrote:
>>> >> >>>>>
>>> >> >>>>> On 29/5/18 4:26 am, Joel Sherrill wrote:
>>> >> >>>>> > On Mon, May 28, 2018 at 5:43 AM, Vijay Kumar Banerjee
>>> >> >>>>> > >> >> >>>>> > <mailto:vijaykumar9...@gmail.com>> wrote:
>>> >> >>>>> >
>>> >> >>>>> > Hello,
>>> >> >>>>> >
>>> >> >>>>> > The coverage reports are now showing results.
>>> >> >>>>> > The current branch that holds all the changes is
>>> >> >>>>> > the cov-tester-support branch in my forked repo
>>> >> >>>>> >
>>> >> >>>>> >
>>> >> >>>>> >
>>> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support
>>> >> >>>>> >
>>> >> >>>>> >
>>> >> >>>>> > <
>>> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support>
>>> >> >>>>> >
>>> >> >>>>> > (Please have a look into the code and test it.)
>>> >> >>>>> >
>>> >> >>>>> > It is close to merging (hopefully). These are the issues
>>> >> >>>>> > that would need a fix before it can be merged :
>>> >> >>>>> >
>>> >> >>>>> > 1. I have added some #FIXME in the code (have a look)
>>> >>

Re: [PATCH] Generate coverage analysis Report

[Cillian O'Donnell]

On Wed, 30 May 2018, 18:21 Gedare Bloom,  wrote:

> Please provide your name in your commits (git config --user.name "My
> Name") that you submit.
>
> The first line of this commit, and therefore the email subject, is
> overly vague. Provide a slightly more specific description.
>
> On Wed, May 30, 2018 at 1:00 PM, thelunatic 
> wrote:
> > + Add script to run covoar and generate an html report from
> > the output generated from covoar
> > + Add symbol-sets ini file for library addresses of the symbol-sets
> > + tester/rt/test : Add options for running coverage
> >
>
> I'd rather see a narrative paragraph than this list of + bullet items.
> Are all of these changes required to run the report? Should they be
> broken into smaller commits that are logically related but separately
> reviewable and commited?
>
> > Co-author : Cillian O'Donnel 
> I don't know what Co-Author should mean. I would prefer to receive
> separate commits/patches for contributions made by different people if
> that is possible.
>
Krystof is the original author for coverage.py, I rewrote large sections of
it and now Vijay has made some changes. It would be difficult to separate
out exactly who did what at this stage. I don't mind who gets the credit
for what, as long as it gets merged.

>
> > ---
> >  tester/rt/coverage.py | 380
> ++
> >  tester/rt/test.py |  36 ++-
> >  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
> >  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
> >  tester/rtems/testing/qemu.cfg |   4 +-
> >  5 files changed, 447 insertions(+), 12 deletions(-)
> >  create mode 100644 tester/rt/coverage.py
> >  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
> >
> > diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> > new file mode 100644
> > index 000..38dcce6
> > --- /dev/null
> > +++ b/tester/rt/coverage.py
> > @@ -0,0 +1,380 @@
> > +#
> > +# RTEMS Tools Project (http://www.rtems.org/)
> > +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
>
> Is this Krzysztof's code? if so, it should be added as a commit with
> him as the --author="" field of git-commit option.
>
> > +# All rights reserved.
> > +#
> > +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> > +#
> > +# Redistribution and use in source and binary forms, with or without
> > +# modification, are permitted provided that the following conditions
> are met:
> > +#
> > +# 1. Redistributions of source code must retain the above copyright
> notice,
> > +# this list of conditions and the following disclaimer.
> > +#
> > +# 2. Redistributions in binary form must reproduce the above copyright
> notice,
> > +# this list of conditions and the following disclaimer in the
> documentation
> > +# and/or other materials provided with the distribution.
> > +#
> > +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> 'AS IS'
> > +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> > +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> > +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
> CONTRIBUTORS BE
> > +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> > +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> > +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
> IN
> > +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> > +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
> OF THE
> > +# POSSIBILITY OF SUCH DAMAGE.
> > +#
> > +
> > +from rtemstoolkit import error
> > +from rtemstoolkit import path
> > +from rtemstoolkit import log
> > +from rtemstoolkit import execute
> > +from rtemstoolkit import macros
> > +
> > +from datetime import datetime
> > +
> > +from . import options
> > +
> > +import shutil
> > +import os
> > +
> > +try:
> > +import configparser
> > +except:
> > +import ConfigParser as configparser
> > +
> > +class summary:
> > +def __init__(self, p_summary_dir):
> > +self.summary_file_path = path.join(p_summary_dir, 'summary.txt')
> > +self.index_file_path = path.join(p_summary_dir, 'index.html')
> > +self.bytes_analyzed = 0
> > +self.bytes_not_executed = 0
> > +self.percentage_executed = 0.0
> > +self.percentage_not_executed = 100.0
> > +self.ranges_uncovered = 0
> > +self.branches_uncovered = 0
> > +self.branches_total = 0
> > +self.branches_always_taken = 0
> > +self.branches_never_taken = 0
> > +self.percentage_branches_covered = 0.0
> > +self.is_failure = False
> > +
> > +def parse(self):
> > +if(not path.exists(self.summary_file_path)):
> > +log.notice('summary file %s does not exi

Re: [PATCH] Generate coverage analysis Report

[Cillian O'Donnell]

On Wed, 30 May 2018, 18:54 Vijay Kumar Banerjee, 
wrote:

> On 30 May 2018 at 22:51, Gedare Bloom  wrote:
>
>> Please provide your name in your commits (git config --user.name "My
>> Name") that you submit.
>>
>> OK Noted :)
>
>> The first line of this commit, and therefore the email subject, is
>> overly vague. Provide a slightly more specific description.
>>
> On Wed, May 30, 2018 at 1:00 PM, thelunatic 
>> wrote:
>> > + Add script to run covoar and generate an html report from
>> > the output generated from covoar
>> > + Add symbol-sets ini file for library addresses of the symbol-sets
>> > + tester/rt/test : Add options for running coverage
>> >
>>
>
>> I'd rather see a narrative paragraph than this list of + bullet items.
>> Are all of these changes required to run the report? Should they be
>> broken into smaller commits that are logically related but separately
>> reviewable and commited?
>>
>> OK, I will write in a descriptive paragraph.
> These changes are all needed to run coverage.
>
>> > Co-author : Cillian O'Donnel 
>> I don't know what Co-Author should mean. I would prefer to receive
>> separate commits/patches for contributions made by different people if
>> that is possible.
>>
>> Plese refer below...
>
>> > ---
>> >  tester/rt/coverage.py | 380
>> ++
>> >  tester/rt/test.py |  36 ++-
>> >  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>> >  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>> >  tester/rtems/testing/qemu.cfg |   4 +-
>> >  5 files changed, 447 insertions(+), 12 deletions(-)
>> >  create mode 100644 tester/rt/coverage.py
>> >  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>> >
>> > diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>> > new file mode 100644
>> > index 000..38dcce6
>> > --- /dev/null
>> > +++ b/tester/rt/coverage.py
>> > @@ -0,0 +1,380 @@
>> > +#
>> > +# RTEMS Tools Project (http://www.rtems.org/)
>> > +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
>>
>> Is this Krzysztof's code? if so, it should be added as a commit with
>> him as the --author="" field of git-commit option.
>>
>> Actually this script has undergone a lot of updates.
> It doesn't even work the same way it used to. I am uncertain
> about the portions of the code that are written by him and still in
> the script. Basically I left the copyright notice untouched and
> let it be there because I am unsure of what to include there.
> Same is true in case of Cillian. I don't really know how much
> of Code is authored by him.
> It surely isn't the proper way to add him as the co-author in
> the log but that seemed like the only way to include him.
>
>
>> > +# All rights reserved.
>> > +#
>> > +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> > +#
>> > +# Redistribution and use in source and binary forms, with or without
>> > +# modification, are permitted provided that the following conditions
>> are met:
>> > +#
>> > +# 1. Redistributions of source code must retain the above copyright
>> notice,
>> > +# this list of conditions and the following disclaimer.
>> > +#
>> > +# 2. Redistributions in binary form must reproduce the above copyright
>> notice,
>> > +# this list of conditions and the following disclaimer in the
>> documentation
>> > +# and/or other materials provided with the distribution.
>> > +#
>> > +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> 'AS IS'
>> > +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
>> TO, THE
>> > +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>> PURPOSE
>> > +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
>> CONTRIBUTORS BE
>> > +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> > +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> > +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> BUSINESS
>> > +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
>> IN
>> > +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
>> OTHERWISE)
>> > +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
>> OF THE
>> > +# POSSIBILITY OF SUCH DAMAGE.
>> > +#
>> > +
>> > +from rtemstoolkit import error
>> > +from rtemstoolkit import path
>> > +from rtemstoolkit import log
>> > +from rtemstoolkit import execute
>> > +from rtemstoolkit import macros
>> > +
>> > +from datetime import datetime
>> > +
>> > +from . import options
>> > +
>> > +import shutil
>> > +import os
>> > +
>> > +try:
>> > +import configparser
>> > +except:
>> > +import ConfigParser as configparser
>> > +
>> > +class summary:
>> > +def __init__(self, p_summary_dir):
>> > +self.summary_file_path = path.join(p_summary_dir,
>> 'summary.txt')
>> > +self.index_file_path = path.join(p_summary_dir, 'index.html')
>> > +self.byt

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Cillian O'Donnell]

On 31 May 2018 at 19:07, Vijay Kumar Banerjee 
wrote:

> Add support in tester to run covoar and generate an html report to display
> the summary of the coverage reports generated from covoar.
>
> Co-authored-by : Cillian O'Donnell 
> ---
>  tester/rt/coverage.py | 379
> ++
>  tester/rt/test.py |  36 ++-
>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>  tester/rtems/testing/qemu.cfg |   4 +-
>  5 files changed, 446 insertions(+), 12 deletions(-)
>  create mode 100644 tester/rt/coverage.py
>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>
> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
> new file mode 100644
> index 000..25fbb9d
> --- /dev/null
> +++ b/tester/rt/coverage.py
> @@ -0,0 +1,379 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are
> met:
> +#
> +# 1. Redistributions of source code must retain the above copyright
> notice,
> +# this list of conditions and the following disclaimer.
> +#
> +# 2. Redistributions in binary form must reproduce the above copyright
> notice,
> +# this list of conditions and the following disclaimer in the
> documentation
> +# and/or other materials provided with the distribution.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 'AS
> IS'
> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS
> BE
> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> +# POSSIBILITY OF SUCH DAMAGE.
> +#
> +
> +from rtemstoolkit import error
> +from rtemstoolkit import path
> +from rtemstoolkit import log
> +from rtemstoolkit import execute
> +from rtemstoolkit import macros
> +
> +from datetime import datetime
> +
> +from . import options
> +
> +import shutil
> +import os
> +
> +try:
> +import configparser
> +except:
> +import ConfigParser as configparser
> +
> +class summary:
> +def __init__(self, p_summary_dir):
> +self.summary_file_path = path.join(p_summary_dir, 'summary.txt')
> +self.index_file_path = path.join(p_summary_dir, 'index.html')
> +self.bytes_analyzed = 0
> +self.bytes_not_executed = 0
> +self.percentage_executed = 0.0
> +self.percentage_not_executed = 100.0
> +self.ranges_uncovered = 0
> +self.branches_uncovered = 0
> +self.branches_total = 0
> +self.branches_always_taken = 0
> +self.branches_never_taken = 0
> +self.percentage_branches_covered = 0.0
> +self.is_failure = False
> +
> +def parse(self):
> +if(not path.exists(self.summary_file_path)):
> +log.notice('summary file %s does not exist!' %
> (self.summary_file_path))
> +self.is_failure = True
> +return
> +
> +with open(self.summary_file_path,'r') as summary_file:
> +   self.bytes_analyzed = self._get_next_with_colon(summary_file)
> +   self.bytes_not_executed = self._get_next_with_colon(
> summary_file)
> +   self.percentage_executed = self._get_next_with_colon(
> summary_file)
> +   self.percentage_not_executed = self._get_next_with_colon(
> summary_file)
> +   self.ranges_uncovered = self._get_next_with_colon(
> summary_file)
> +   self.branches_total = self._get_next_with_colon(summary_file)
> +   self.branches_uncovered = self._get_next_with_colon(
> summary_file)
> +   self.branches_always_taken = self._get_next_without_colon(
> summary_file)
> +   self.branches_never_taken = self._get_next_without_colon(
> summary_file)
> +  

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Cillian O'Donnell]

So is it checking whether it's --coverage or --coverage=set1,set2? Are
those the 2 possibilities your checking?

On Thu, 31 May 2018, 20:52 Vijay Kumar Banerjee, 
wrote:

> On 1 June 2018 at 01:19, Gedare Bloom  wrote:
>
>> On Thu, May 31, 2018 at 3:47 PM, Vijay Kumar Banerjee
>>  wrote:
>> > On 1 June 2018 at 01:07, Cillian O'Donnell 
>> wrote:
>> >>
>> >>
>> >>
>> >> On 31 May 2018 at 19:07, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com>
>> >> wrote:
>> >>>
>> >>> Add support in tester to run covoar and generate an html report to
>> >>> display
>> >>> the summary of the coverage reports generated from covoar.
>> >>>
>> >>> Co-authored-by : Cillian O'Donnell 
>> >>> ---
>> >>>  tester/rt/coverage.py | 379
>> >>> ++
>> >>>  tester/rt/test.py |  36 ++-
>> >>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>> >>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>> >>>  tester/rtems/testing/qemu.cfg |   4 +-
>> >>>  5 files changed, 446 insertions(+), 12 deletions(-)
>> >>>  create mode 100644 tester/rt/coverage.py
>> >>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>> >>>
>> >>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>> >>> new file mode 100644
>> >>> index 000..25fbb9d
>> >>> --- /dev/null
>> >>> +++ b/tester/rt/coverage.py
>> >>> @@ -0,0 +1,379 @@
>> >>> +#
>> >>> +# RTEMS Tools Project (http://www.rtems.org/)
>> >>> +# Copyright 2014 Krzysztof Miesowicz (krzysztof.miesow...@gmail.com)
>> >>> +# All rights reserved.
>> >>> +#
>> >>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>> >>> +#
>> >>> +# Redistribution and use in source and binary forms, with or without
>> >>> +# modification, are permitted provided that the following conditions
>> are
>> >>> met:
>> >>> +#
>> >>> +# 1. Redistributions of source code must retain the above copyright
>> >>> notice,
>> >>> +# this list of conditions and the following disclaimer.
>> >>> +#
>> >>> +# 2. Redistributions in binary form must reproduce the above
>> copyright
>> >>> notice,
>> >>> +# this list of conditions and the following disclaimer in the
>> >>> documentation
>> >>> +# and/or other materials provided with the distribution.
>> >>> +#
>> >>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>> >>> 'AS IS'
>> >>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
>> TO,
>> >>> THE
>> >>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>> >>> PURPOSE
>> >>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
>> CONTRIBUTORS
>> >>> BE
>> >>> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> >>> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
>> OF
>> >>> +# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> >>> BUSINESS
>> >>> +# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
>> WHETHER
>> >>> IN
>> >>> +# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
>> >>> OTHERWISE)
>> >>> +# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
>> ADVISED OF
>> >>> THE
>> >>> +# POSSIBILITY OF SUCH DAMAGE.
>> >>> +#
>> >>> +
>> >>> +from rtemstoolkit import error
>> >>> +from rtemstoolkit import path
>> >>> +from rtemstoolkit import log
>> >>> +from rtemstoolkit import execute
>> >>> +from rtemstoolkit import macros
>> >>> +
>> >>> +from datetime import datetime
>> >>> +
>> >>> +from . import options
>> >>> +
>> >>> +import shutil
>> >>> +import os
>> >>> +
>> >>&g

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Cillian O'Donnell]

There is now a seperate bsp config for coverage, leon3-qemu-cov. That is
enough to trigger coverage now and --coverage could be reserved for picking
sets, probably renamed to --coverage-sets=... Or require sets to be chosen
--coverage-sets=all or specific sets --coverage-sets=score,sapi,core

On Thu, 31 May 2018, 21:29 Vijay Kumar Banerjee, 
wrote:

> On 1 June 2018 at 01:57, Cillian O'Donnell  wrote:
>
>> So is it checking whether it's --coverage or --coverage=set1,set2? Are
>> those the 2 possibilities your checking?
>>
>> Yes, right. :)
>
>> On Thu, 31 May 2018, 20:52 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 1 June 2018 at 01:19, Gedare Bloom  wrote:
>>>
>>>> On Thu, May 31, 2018 at 3:47 PM, Vijay Kumar Banerjee
>>>>  wrote:
>>>> > On 1 June 2018 at 01:07, Cillian O'Donnell 
>>>> wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> On 31 May 2018 at 19:07, Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com>
>>>> >> wrote:
>>>> >>>
>>>> >>> Add support in tester to run covoar and generate an html report to
>>>> >>> display
>>>> >>> the summary of the coverage reports generated from covoar.
>>>> >>>
>>>> >>> Co-authored-by : Cillian O'Donnell 
>>>> >>> ---
>>>> >>>  tester/rt/coverage.py | 379
>>>> >>> ++
>>>> >>>  tester/rt/test.py |  36 ++-
>>>> >>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>>> >>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>>> >>>  tester/rtems/testing/qemu.cfg |   4 +-
>>>> >>>  5 files changed, 446 insertions(+), 12 deletions(-)
>>>> >>>  create mode 100644 tester/rt/coverage.py
>>>> >>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>>>> >>>
>>>> >>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>>>> >>> new file mode 100644
>>>> >>> index 000..25fbb9d
>>>> >>> --- /dev/null
>>>> >>> +++ b/tester/rt/coverage.py
>>>> >>> @@ -0,0 +1,379 @@
>>>> >>> +#
>>>> >>> +# RTEMS Tools Project (http://www.rtems.org/)
>>>> >>> +# Copyright 2014 Krzysztof Miesowicz (
>>>> krzysztof.miesow...@gmail.com)
>>>> >>> +# All rights reserved.
>>>> >>> +#
>>>> >>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>>>> >>> +#
>>>> >>> +# Redistribution and use in source and binary forms, with or
>>>> without
>>>> >>> +# modification, are permitted provided that the following
>>>> conditions are
>>>> >>> met:
>>>> >>> +#
>>>> >>> +# 1. Redistributions of source code must retain the above copyright
>>>> >>> notice,
>>>> >>> +# this list of conditions and the following disclaimer.
>>>> >>> +#
>>>> >>> +# 2. Redistributions in binary form must reproduce the above
>>>> copyright
>>>> >>> notice,
>>>> >>> +# this list of conditions and the following disclaimer in the
>>>> >>> documentation
>>>> >>> +# and/or other materials provided with the distribution.
>>>> >>> +#
>>>> >>> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
>>>> CONTRIBUTORS
>>>> >>> 'AS IS'
>>>> >>> +# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>>>> LIMITED TO,
>>>> >>> THE
>>>> >>> +# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
>>>> PARTICULAR
>>>> >>> PURPOSE
>>>> >>> +# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR
>>>> CONTRIBUTORS
>>>> >>> BE
>>>> >>> +# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
>>>> OR
>>>> >>> +# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
>>>>

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Cillian O'Donnell]

On Thu, 31 May 2018, 22:03 Vijay Kumar Banerjee, 
wrote:

> On 1 June 2018 at 02:14, Cillian O'Donnell  wrote:
>
>> There is now a seperate bsp config for coverage, leon3-qemu-cov. That is
>> enough to trigger coverage now and --coverage could be reserved for picking
>> sets, probably renamed to --coverage-sets=... Or require sets to be chosen
>> --coverage-sets=all or specific sets --coverage-sets=score,sapi,core
>>
>> Actually the idea of having separate bsp configs for cov
> in each of the bsps will create a lot of files. The intention is
> to make it simple for the user. just adding --coverage
> should run coverage analysis. There's a plan to include
> the 'coverage' section into the bsp ini file, and hence the user wouldn't
> have to keep switching the bsp config files.
>

Actually that's exactly the way I had it working before Chris' recent
changes, he had a look at the way it's working and chose to create seperate
bsp config files. That may be the way he'd prefer. This was before the
--coverage option had another use other than triggering coverage, so his
thoughts may have changed on it.

>
> The idea of modifying it to --coverage-sets=all ;
> --coverage-sets=set1,set2,set3. can surely be implemented
> in place of --coverage ; --coverage=set1,set2
>
>> On Thu, 31 May 2018, 21:29 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 1 June 2018 at 01:57, Cillian O'Donnell 
>>> wrote:
>>>
>>>> So is it checking whether it's --coverage or --coverage=set1,set2? Are
>>>> those the 2 possibilities your checking?
>>>>
>>>> Yes, right. :)
>>>
>>>> On Thu, 31 May 2018, 20:52 Vijay Kumar Banerjee, <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> On 1 June 2018 at 01:19, Gedare Bloom  wrote:
>>>>>
>>>>>> On Thu, May 31, 2018 at 3:47 PM, Vijay Kumar Banerjee
>>>>>>  wrote:
>>>>>> > On 1 June 2018 at 01:07, Cillian O'Donnell 
>>>>>> wrote:
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> On 31 May 2018 at 19:07, Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com>
>>>>>> >> wrote:
>>>>>> >>>
>>>>>> >>> Add support in tester to run covoar and generate an html report to
>>>>>> >>> display
>>>>>> >>> the summary of the coverage reports generated from covoar.
>>>>>> >>>
>>>>>> >>> Co-authored-by : Cillian O'Donnell 
>>>>>> >>> ---
>>>>>> >>>  tester/rt/coverage.py | 379
>>>>>> >>> ++
>>>>>> >>>  tester/rt/test.py |  36 ++-
>>>>>> >>>  tester/rtems/testing/bsps/leon3-qemu-cov.ini  |   3 +-
>>>>>> >>>  tester/rtems/testing/coverage/symbol-sets.ini |  36 +++
>>>>>> >>>  tester/rtems/testing/qemu.cfg |   4 +-
>>>>>> >>>  5 files changed, 446 insertions(+), 12 deletions(-)
>>>>>> >>>  create mode 100644 tester/rt/coverage.py
>>>>>> >>>  create mode 100644 tester/rtems/testing/coverage/symbol-sets.ini
>>>>>> >>>
>>>>>> >>> diff --git a/tester/rt/coverage.py b/tester/rt/coverage.py
>>>>>> >>> new file mode 100644
>>>>>> >>> index 000..25fbb9d
>>>>>> >>> --- /dev/null
>>>>>> >>> +++ b/tester/rt/coverage.py
>>>>>> >>> @@ -0,0 +1,379 @@
>>>>>> >>> +#
>>>>>> >>> +# RTEMS Tools Project (http://www.rtems.org/)
>>>>>> >>> +# Copyright 2014 Krzysztof Miesowicz (
>>>>>> krzysztof.miesow...@gmail.com)
>>>>>> >>> +# All rights reserved.
>>>>>> >>> +#
>>>>>> >>> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
>>>>>> >>> +#
>>>>>> >>> +# Redistribution and use in source and binary forms, with or
>>>>>> without
>>>>>> >>> +# modification, are permitted provided that

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Cillian O'Donnell]

On 4 June 2018 at 19:03, Vijay Kumar Banerjee 
wrote:

> On 2 June 2018 at 01:00, Vijay Kumar Banerjee 
> wrote:
>
>> On 2 June 2018 at 00:48, Joel Sherrill  wrote:
>>
>>>
>>>
>>> On Fri, Jun 1, 2018, 11:21 AM Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 1 June 2018 at 20:30, Gedare Bloom  wrote:

> On Fri, Jun 1, 2018 at 10:28 AM, Vijay Kumar Banerjee
>  wrote:
> > On 1 June 2018 at 19:24, Joel Sherrill  wrote:
> >>
> >>
> >>
> >> On Fri, Jun 1, 2018 at 2:46 AM, Vijay Kumar Banerjee
> >>  wrote:
> >>>
> >>> Here's the list of Ideas for improvements:
> >>>
> >>> 1. Include the section coverage in the bsp config file.
> >>> If the section is not found then the script will show
> >>> proper error showing coverage is not supported for the
> >>> provided bsp config file.
> >>>
> >>> 2. Update covoar to add support for separate coverage report
> >>> for each symbol set.
> >>>
> >>> 3. Add a method somewhere in covoar to get the size of an
> instruction
> >>> and fix the hard coded size 4 in ObjdumpProcessor.cc
> >>
> >>
> >> What about a single XXX_run command? What about that suggestion?
> >>
> > The suggestion was to turn test_run and coverage_run into a single
> command.
> > I have kept them separate so that there's a possibility to just run
> the
> > test.
> >
> > If we want to run coverage everytime we run the test. we can do it.
> > Then I think the --coverage option can be changed to --coverage-sets
> > to mention the sets.
> > If that's what we're looking for then I don't think a separate
> ticket is
> > needed,
> > I can try to do it within tomorrow and submit an updated patch.
> >
> >>
> >> Will there be an update to this patch?
> >>
> > This patch is working an showing results. I don't have any work
> > going related to this patch currently.
> > If there are any suggestions, I'll try to include all the suggested
> updates
> > as soon as possible and submit. So that we can get it merged.
> >
>
> I get confused by the similarity between test_run() and coverage_run()
> names, and now I'm also seeing some confusion because there is a
> function coverage_run() and a class coverage_run. I suggest you remove
> this function coverage_run(), and make either coverage_run.__init__()
> or coverage_run.run() take the executables as a parameter directly.
>
> Thank you for the suggestion. :)
 I have removed the function and taken executables as a parameter in
 coverage_run.__init__()

 I have a question.
 The ini file that is fed to covoar is written by the script according
 to the
 symbols mentioned by the user. I haven't include the ini file in the
 patch.
 I'm planning to delete the file after the run, unless --no-clean option
 is given,
 which currently deletes the .cov trace files after the run.

>>>
>>> That makes sense.
>>>
>>>
 Can I proceed with this ?

>>>
>>> Yes.
>>>
>> Added. Thanks. :)
>>
>>> also, shall I include that in the .gitignore ?

>>>
>>> Is the name of the file constant? The same across multiple BSPs? If so,
>>> then this will be a problem doing automated testing of multiple BSPs in
>>> parallel.
>>>
>>> The ini file I'm talking about is the symbol sets config file not the bsp
>> config file. yes the name is constant. Should it be unique to the bsp ?
>> something like, leon3-symbols.ini ?
>> How does the automated testing work?
>>
>>> I think the name needs to be unique enough.to support running testing
>>> with coverage on multiple BSPs in parallel. That means you can't add it to
>>> gitignore. And can add another issue and FIXME to the code.
>>>
 If it is needed then I have a fix in mind. I can take the bsp name and
>> add
>> '-symbols.ini' to it. and add *-symbols.ini to .gitignore .
>>
> Shall I add this or put a fixme in the code and post a patch ?
> Are there any other suggestions for the patch ?
>
> I was looking into covoar for generating separate reports for each
> symbolset.
> Seems like  all the coverage reports are generated together and are written
> in the _outputDirectory_ .
>

The output directory should be aligned with the bsp and the report.html
changed to keep record of this instead of searching for the generic
coverage dir. Look for leon3-coverage and so on. As well as the
symbol-sets.ini change you mentioned above. That would probably be enough
to not cause any conflicts with parallel testing (I may be missing a case
there, I let you know if anything else comes to mind). The main thing to
think about is if multiple bsps are being tested at the same time, they
have to know which config file is there's and which output directory and
whatever else they may be looking for, the names have to be unique. These
things are all fed to covoar so

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Cillian O'Donnell]

On 4 June 2018 at 20:29, Vijay Kumar Banerjee 
wrote:

> On 5 June 2018 at 00:51, Joel Sherrill  wrote:
>
>>
>>
>> On Mon, Jun 4, 2018 at 2:12 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 5 June 2018 at 00:31, Joel Sherrill  wrote:
>>>
>>>> I will add that covoar was originally designed to generate a report on
>>>> one
>>>> set at a time. The iteration over symbol sets was done at the scripting
>>>> level above that.
>>>>
>>>> This had the advantage of being simple at the time. It may still be
>>>> simple
>>>> but moving the iteration over sets to covoar will probably be faster.
>>>>
>>>> I think DesiredSymbols is instanced a single time. As a starting point,
>>>> there
>>>> would have to be multiple instances of this -- one for each symbol set.
>>>>
>>>> Beyond that, there is a correlation between the report generated and
>>>> the desired symbols set.
>>>>
>>>> So I am thinking that we need to define a "context" structure for each
>>>> set. One simple thought is that there is one "master/unified"
>>>> DesiredSymbol
>>>> set under the hood and the symbols in each set are used as a filter
>>>> when generating reports. So process the executables for every symbol
>>>> but generate the report subdirectories based on one of the sets of
>>>> DesiredSymbols.
>>>>
>>>> I think that should work.
>>>>
>>>> Cillian.. you have been through the flow. Am I thinking right that it
>>>> is
>>>>
>>> That sounds like it will work, I'll go back over the covoar code and
have a think about it. See if I can find any road blocks.


>
>>>> And I think we need to merge before doing this type of work. If we can
>>>> process
>>>> a single set correctly, that's a baseline. Adding iteration will be
>>>> easier to review
>>>> as another patch.
>>>>
>>>>
>>> we can process a single set correctly.
>>> Shall we proceed with merging the above patch with the suggested small
>>> edits
>>> and then file a ticket for the iteration and then start working on it ?
>>>
>>
>> Please.
>>
>>>
>>> I am confused with running of coverage for multiple bsp. If a single
>>> report.html has to show the reports of multiple bsps (as hinted by
>>> Cillian)
>>>
>> Actually I meant separate report.htmls, but if they're all outputed in
the the top level directory there'll have to be something internal to know
to search for the right output directory with all the coverage data, that's
all I meant. Nothing major.


> Then a lot of rewroking would be needed. If we're headed in that way
>>> then I think making separate report.html like leon3-report.html would be
>>> simpler
>>> to achieve, and then create a master index.html for listing all the
>>> report htmls.
>>>
>>
>> A single run of the tester will test a single BSP. If you open two shell
>> windows
>> and run the tester in both, will those collide?
>>
>> In it's current state. Yes, it will collide as all the names of files
> (including report.html)
> are constant. :(
>
This is the main fix for now just making adding unique identifiers for
files and dirs that will be called in the process. Focus on that, then we
can try and merge and the covoar fix for multi sets can come later.

> covoar does not need support internally to process multiple BSPs
>> concurrently.
>>
>> It is common practice to build and test multiple BSPs in parallel to take
>> advantage
>> of machines with many cores.
>>
>> But if you aren't careful, you can't even have two build/test trees at
>> the same time
>> if they collide on file names in shared directories.
>>
>> Does that make sense?
>>
>>
>>>> On Mon, Jun 4, 2018 at 1:43 PM, Cillian O'Donnell <
>>>> cpodonne...@gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 4 June 2018 at 19:03, Vijay Kumar Banerjee <
>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>
>>>>>> On 2 June 2018 at 01:00, Vijay Kumar Banerjee <
>>>>>> vijaykumar9...@gmail.com> wrote:
>>>>>>
>>>>>>> On 2 June 2018 at 00:48, Joel Sherrill  wrote:
>&g

Re: [PATCH v2] tester: Add script to generate html coverage report from covoar output

[Cillian O'Donnell]

On Mon, 4 Jun 2018, 21:20 Vijay Kumar Banerjee, 
wrote:

> On 5 June 2018 at 01:28, Cillian O'Donnell  wrote:
>
>>
>>
>> On 4 June 2018 at 20:29, Vijay Kumar Banerjee 
>> wrote:
>>
>>> On 5 June 2018 at 00:51, Joel Sherrill  wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jun 4, 2018 at 2:12 PM, Vijay Kumar Banerjee <
>>>> vijaykumar9...@gmail.com> wrote:
>>>>
>>>>> On 5 June 2018 at 00:31, Joel Sherrill  wrote:
>>>>>
>>>>>> I will add that covoar was originally designed to generate a report
>>>>>> on one
>>>>>> set at a time. The iteration over symbol sets was done at the
>>>>>> scripting
>>>>>> level above that.
>>>>>>
>>>>>> This had the advantage of being simple at the time. It may still be
>>>>>> simple
>>>>>> but moving the iteration over sets to covoar will probably be faster.
>>>>>>
>>>>>> I think DesiredSymbols is instanced a single time. As a starting
>>>>>> point, there
>>>>>> would have to be multiple instances of this -- one for each symbol
>>>>>> set.
>>>>>>
>>>>>> Beyond that, there is a correlation between the report generated and
>>>>>> the desired symbols set.
>>>>>>
>>>>>> So I am thinking that we need to define a "context" structure for each
>>>>>> set. One simple thought is that there is one "master/unified"
>>>>>> DesiredSymbol
>>>>>> set under the hood and the symbols in each set are used as a filter
>>>>>> when generating reports. So process the executables for every symbol
>>>>>> but generate the report subdirectories based on one of the sets of
>>>>>> DesiredSymbols.
>>>>>>
>>>>>> I think that should work.
>>>>>>
>>>>>> Cillian.. you have been through the flow. Am I thinking right that it
>>>>>> is
>>>>>>
>>>>> That sounds like it will work, I'll go back over the covoar code and
>> have a think about it. See if I can find any road blocks.
>>
>>
>>>
>>>>>> And I think we need to merge before doing this type of work. If we
>>>>>> can process
>>>>>> a single set correctly, that's a baseline. Adding iteration will be
>>>>>> easier to review
>>>>>> as another patch.
>>>>>>
>>>>>>
>>>>> we can process a single set correctly.
>>>>> Shall we proceed with merging the above patch with the suggested small
>>>>> edits
>>>>> and then file a ticket for the iteration and then start working on it ?
>>>>>
>>>>
>>>> Please.
>>>>
>>>>>
>>>>> I am confused with running of coverage for multiple bsp. If a single
>>>>> report.html has to show the reports of multiple bsps (as hinted by
>>>>> Cillian)
>>>>>
>>>> Actually I meant separate report.htmls, but if they're all outputed in
>> the the top level directory there'll have to be something internal to know
>> to search for the right output directory with all the coverage data, that's
>> all I meant. Nothing major.
>>
>>
>>> Then a lot of rewroking would be needed. If we're headed in that way
>>>>> then I think making separate report.html like leon3-report.html would
>>>>> be simpler
>>>>> to achieve, and then create a master index.html for listing all the
>>>>> report htmls.
>>>>>
>>>>
>>>> A single run of the tester will test a single BSP. If you open two
>>>> shell windows
>>>> and run the tester in both, will those collide?
>>>>
>>>> In it's current state. Yes, it will collide as all the names of files
>>> (including report.html)
>>> are constant. :(
>>>
>> This is the main fix for now just making adding unique identifiers for
>> files and dirs that will be called in the process. Focus on that, then we
>> can try and merge and the covoar fix for multi sets can come later.
>>
> I have added the update .
> after the update the directory is BSP-coverage ( example :-
> leon3-qemu-coverage)
> they symbol fi