Generating separate coverage reports for different symbol-sets from covoar

[Vijay Kumar Banerjee]

Hello,

The covoar currently is capable of processing multisets
from the symbol-sets ini file, however, it currently keeps
all the reports in the same directory (../coverage/score).

Before the recent updates to covoar it could only read
one set/subsystem from an ini file, and the script used
to loop over to feed covoar the ini files and store them
in a separate directory. Now this support needs to be
added to covoar .

The report.html generated from coverage has the
support for reading from different directories.
example:- ../coverage/score , ../coverage/rtems etc.
so just creating a directory for result in each iteration
of sets would solve this (I think)

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

Re: [PATCH] Generate coverage analysis Report

[Vijay Kumar Banerjee]

On 31 May 2018 at 02:02, Joel Sherrill  wrote:

>
>
> On Wed, May 30, 2018 at 3:29 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 31 May 2018 at 00:28, Joel Sherrill  wrote:
>>
>>>
>>>
>>> I may not understand correctly but there is test_run and coverage_run.
>>> Someone
>>> suggested making coverage_running an option to test_run. If that's
>>> what's being
>>> asked for, then I think doing it in a follow up patch is OK.
>>>
>>> If that's the intended request, perhaps a ticket should be filed.
>>>
>>>
>> Sorry for all the confusion.
>> This patch doesn't change the way test works. It only adds an option to
>> run
>> the coverage script. coverage_run just runs the coverage.coverage_run
>>
>
> :) And I am saying if we want to have one test_run with an argument, do it
> as
> a future work iteration. File a ticket.
>
> We need to get the code working on the master.
>
> Okay, we can keep that as a future work (I haven't thought about it
though). :)
Getting it to work on master is our primary objective.


>
>> >
>>> >  except error.general as gerr:
>>> >  print(gerr)
>>> > diff --git a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>>> b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>>> > index 6b5e7e6..2f89117 100644
>>> > --- a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>>> > +++ b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>>> > @@ -31,9 +31,10 @@
>>> >  #
>>> >  # The Leon 3 QEMU BSP
>>> >  #
>>> > -[leon3-qemu]
>>> > +[leon3-qemu-cov]
>>> >  bsp   = leon3-qemu
>>> >  arch  = sparc
>>> > +target= sparc-rtems5
>>> >  tester= %{_rtscripts}/qemu.cfg
>>> >  bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
>>> >  bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
>>> > diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
>>> b/tester/rtems/testing/coverage/symbol-sets.ini
>>> > new file mode 100644
>>> > index 000..a2ec7bc
>>> > --- /dev/null
>>> > +++ b/tester/rtems/testing/coverage/symbol-sets.ini
>>> > @@ -0,0 +1,36 @@
>>> > +#
>>> > +# RTEMS Tools Project (http://www.rtems.org/)
>>> > +# Copyright 2018 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.
>>> > +#
>>> > +
>>> > +[symbol-sets]
>>> > +sets = score,rtems
>>> > +
>>> > +[libraries]
>>> > +score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>>> > +rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>>> > diff --git a/tester/rtems/testing/qemu.cfg b/tester/rtems/testing/
>>> qemu.cfg
>>> > index bfcd2f5..52a3752 100644
>>> > --- a/tester/rtems/testing/qemu.cfg
>>> > +++ b/tester/rtems/testing/qemu.cfg
>>> > @@ -51,8 +51,8 @@
>>> >  #
>>> >  # 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 none -serial stdio
>>> -nographic
>>> > +#%define qemu_opts_base   -no-reboot -serial null -serial
>>> mon:stdio 

Re: [PATCH] Generate coverage analysis Report

[Joel Sherrill]

On Wed, May 30, 2018 at 3:29 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> On 31 May 2018 at 00:28, Joel Sherrill  wrote:
>
>>
>>
>> I may not understand correctly but there is test_run and coverage_run.
>> Someone
>> suggested making coverage_running an option to test_run. If that's what's
>> being
>> asked for, then I think doing it in a follow up patch is OK.
>>
>> If that's the intended request, perhaps a ticket should be filed.
>>
>>
> Sorry for all the confusion.
> This patch doesn't change the way test works. It only adds an option to
> run
> the coverage script. coverage_run just runs the coverage.coverage_run
>

:) And I am saying if we want to have one test_run with an argument, do it
as
a future work iteration. File a ticket.

We need to get the code working on the master.



> >
>> >  except error.general as gerr:
>> >  print(gerr)
>> > diff --git a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>> b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>> > index 6b5e7e6..2f89117 100644
>> > --- a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>> > +++ b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
>> > @@ -31,9 +31,10 @@
>> >  #
>> >  # The Leon 3 QEMU BSP
>> >  #
>> > -[leon3-qemu]
>> > +[leon3-qemu-cov]
>> >  bsp   = leon3-qemu
>> >  arch  = sparc
>> > +target= sparc-rtems5
>> >  tester= %{_rtscripts}/qemu.cfg
>> >  bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
>> >  bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
>> > diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
>> b/tester/rtems/testing/coverage/symbol-sets.ini
>> > new file mode 100644
>> > index 000..a2ec7bc
>> > --- /dev/null
>> > +++ b/tester/rtems/testing/coverage/symbol-sets.ini
>> > @@ -0,0 +1,36 @@
>> > +#
>> > +# RTEMS Tools Project (http://www.rtems.org/)
>> > +# Copyright 2018 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.
>> > +#
>> > +
>> > +[symbol-sets]
>> > +sets = score,rtems
>> > +
>> > +[libraries]
>> > +score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
>> > +rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
>> > diff --git a/tester/rtems/testing/qemu.cfg b/tester/rtems/testing/
>> qemu.cfg
>> > index bfcd2f5..52a3752 100644
>> > --- a/tester/rtems/testing/qemu.cfg
>> > +++ b/tester/rtems/testing/qemu.cfg
>> > @@ -51,8 +51,8 @@
>> >  #
>> >  # 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 none -serial stdio
>> -nographic
>> > +#%define qemu_opts_base   -no-reboot -serial null -serial
>> mon:stdio -nographic
>>
>> Why changing the common options for qemu?
>>
>> actually it's a bit experimental on advice of Cillian.
> It stayed in the patch.
>

 I know the impact of some of those options but maybe it would make sense
 to add a comment block with the impact of each option? It would help

Re: [PATCH] Generate coverage analysis Report

[Vijay Kumar Banerjee]

On 31 May 2018 at 00:28, Joel Sherrill  wrote:

>
>
> I may not understand correctly but there is test_run and coverage_run.
> Someone
> suggested making coverage_running an option to test_run. If that's what's
> being
> asked for, then I think doing it in a follow up patch is OK.
>
> If that's the intended request, perhaps a ticket should be filed.
>
>
Sorry for all the confusion.
This patch doesn't change the way test works. It only adds an option to run
the coverage script. coverage_run just runs the coverage.coverage_run

> >
> >  except error.general as gerr:
> >  print(gerr)
> > diff --git a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> > index 6b5e7e6..2f89117 100644
> > --- a/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> > +++ b/tester/rtems/testing/bsps/leon3-qemu-cov.ini
> > @@ -31,9 +31,10 @@
> >  #
> >  # The Leon 3 QEMU BSP
> >  #
> > -[leon3-qemu]
> > +[leon3-qemu-cov]
> >  bsp   = leon3-qemu
> >  arch  = sparc
> > +target= sparc-rtems5
> >  tester= %{_rtscripts}/qemu.cfg
> >  bsp_qemu_opts = %{qemu_opts_base} -M leon3_generic
> >  bsp_qemu_cov_opts = -exec-trace %{test_executable}.cov
> > diff --git a/tester/rtems/testing/coverage/symbol-sets.ini
> b/tester/rtems/testing/coverage/symbol-sets.ini
> > new file mode 100644
> > index 000..a2ec7bc
> > --- /dev/null
> > +++ b/tester/rtems/testing/coverage/symbol-sets.ini
> > @@ -0,0 +1,36 @@
> > +#
> > +# RTEMS Tools Project (http://www.rtems.org/)
> > +# Copyright 2018 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.
> > +#
> > +
> > +[symbol-sets]
> > +sets = score,rtems
> > +
> > +[libraries]
> > +score = @BUILD-TARGET@/c/@BSP@/cpukit/score/libscore.a
> > +rtems = @BUILD-TARGET@/c/@BSP@/cpukit/rtems/librtems.a
> > diff --git a/tester/rtems/testing/qemu.cfg b/tester/rtems/testing/
> qemu.cfg
> > index bfcd2f5..52a3752 100644
> > --- a/tester/rtems/testing/qemu.cfg
> > +++ b/tester/rtems/testing/qemu.cfg
> > @@ -51,8 +51,8 @@
> >  #
> >  # 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 none -serial stdio
> -nographic
> > +#%define qemu_opts_base   -no-reboot -serial null -serial mon:stdio
> -nographic
>
> Why changing the common options for qemu?
>
> actually it's a bit experimental on advice of Cillian.
 It stayed in the patch.

>>>
>>> I know the impact of some of those options but maybe it would make sense
>>> to add a comment block with the impact of each option? It would help
>>> future
>>> readers.
>>>
>>> And, from personal experience, qemu changes arguments from time to time.
>>> Knowing
>>> what the old intent was helps mapping to different versions and target
>>> architectures.
>>>
>>> That's a good Idea.
>>
>>>
>>>
>>>
 >  %define qemu_opts_no_net -net none
> >
> >  #
> > --
> > 2.14.3
> >
> > 

Re: [PATCH] Generate coverage analysis Report

[Joel Sherrill]

On Wed, May 30, 2018 at 1:34 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> On 30 May 2018 at 23:29, Joel Sherrill  wrote:
>
>>
>>
>> On Wed, May 30, 2018 at 12:54 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> 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.
>>>
>>
>> OK. I was afraid of it being technically impossible to separate out the
>> work
>> for revision control purposes.
>>
>> Just make sure credit due is given.
>>
>>
>>>
>>>
 > +# 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
 > 

Re: [PATCH] Generate coverage analysis Report

[Vijay Kumar Banerjee]

On 30 May 2018 at 23:29, Joel Sherrill  wrote:

>
>
> On Wed, May 30, 2018 at 12:54 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> 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.
>>
>
> OK. I was afraid of it being technically impossible to separate out the
> work
> for revision control purposes.
>
> Just make sure credit due is given.
>
>
>>
>>
>>> > +# 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
>>> 

Re: [PATCH] Generate coverage analysis Report

[Vijay Kumar Banerjee]

On 30 May 2018 at 22:51, Gedare Bloom  wrote:

> > +def coverage_run(opts, coverage, executables):
> > +coverage.executables = executables
> > +coverage.run()
> > +
> >  def run(command_path = None):
> >  import sys
> >  tests = []
> > @@ -221,15 +228,16 @@ def run(command_path = None):
> >  opts = None
> >  default_exefilter = '*.exe'
> >  try:
> > -optargs = { '--rtems-tools': 'The path to the RTEMS tools',
> > -'--rtems-bsp':   'The RTEMS BSP to run the test on',
> > -'--user-config': 'Path to your local user
> configuration INI file',
> > -'--report-mode': 'Reporting modes, failures
> (default),all,none',
> > -'--list-bsps':   'List the supported BSPs',
> > -'--debug-trace': 'Debug trace based on specific
> flags',
> > -'--filter':  'Glob that executables must match
> to run (default: ' +
> > +optargs = { '--rtems-tools':'The path to the RTEMS tools',
> > +'--rtems-bsp':  'The RTEMS BSP to run the test
> on',
> > +'--user-config':'Path to your local user
> configuration INI file',
> > +'--report-mode':'Reporting modes, failures
> (default),all,none',
> > +'--list-bsps':  'List the supported BSPs',
> > +'--debug-trace':'Debug trace based on specific
> flags',
> > +'--filter': 'Glob that executables must
> match to run (default: ' +
> >default_exefilter + ')',
> > -'--stacktrace':  'Dump a stack trace on a user
> termination (^C)' }
> > +'--stacktrace': 'Dump a stack trace on a user
> termination (^C)',
> > +'--coverage':   'Perform coverage analysis of
> test exectuables.'}
> Why are there changes outside of the last two lines (stacktrace and
> coverage)? Only those two need to be modified to add the new option.
>
> Spaces were added to properly format the code.

> Typo: s/exectuables/executables
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Generate coverage analysis Report

[Joel Sherrill]

On Wed, May 30, 2018 at 12:54 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> 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.
>

OK. I was afraid of it being technically impossible to separate out the work
for revision control purposes.

Just make sure credit due is given.


>
>
>> > +# 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, 

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')
>> > +

Re: [PATCH] Generate coverage analysis Report

[Vijay Kumar Banerjee]

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.bytes_analyzed = 0
> > +self.bytes_not_executed = 0
> > +self.percentage_executed = 0.0
> > +self.percentage_not_executed = 100.0
> > +self.ranges_uncovered = 0
> > +

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 

Re: [PATCH 1/1] Fix and extend error message in posix timer test

[Joel Sherrill]

On Wed, May 30, 2018 at 10:33 AM, Gedare Bloom  wrote:

> This looks fine to me, and I'll commit after I can test it. (We
> currently don't apply any significance to --signed-off-by in RTEMS
> Project.) I'm investigating your inquiry on the 0/1 cover letter.
>

I am ok with it if it tests OK with you.


>
> On Tue, May 15, 2018 at 5:21 AM, Martin Erik Werner
>  wrote:
> > _Timespec_Equal_to() does not set errno, hence avoid using perror(),
> > instead use fprintf() to stderr, and extend the error message to provide
> > information about what the error is (measured timer value after
> > re-arming is not equal to the configured interval), and how large of a
> > difference was measured.
> >
> > Signed-off-by: Martin Erik Werner 
> > ---
> >  testsuites/psxtests/psxtimer01/psxtimer.c | 14 --
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/testsuites/psxtests/psxtimer01/psxtimer.c
> b/testsuites/psxtests/psxtimer01/psxtimer.c
> > index 032e9f8e6c..6ec049ac54 100644
> > --- a/testsuites/psxtests/psxtimer01/psxtimer.c
> > +++ b/testsuites/psxtests/psxtimer01/psxtimer.c
> > @@ -143,7 +143,12 @@ void * task_a (void *arg)
> > rtems_test_exit(0);
> >   }
> >   if (! _Timespec_Equal_to( _value, _period )){
> > -   perror ("Error in Task A timer_gettime\n");
> > +   fprintf(
> > +   stderr, "Error in Task A timer_gettime:\n"
> > +   "  re-armed timer: %" PRIdtime_t ":%ld does not match
> interval: %" PRIdtime_t ":%ld\n",
> > +   timerdata.it_value.tv_sec, timerdata.it_value.tv_nsec,
> > +   my_period.tv_sec, my_period.tv_nsec
> > +  );
> >   }
> >   clock = time(NULL);
> >   printf("Executing task A with count = %2i %s", params->count,
> ctime());
> > @@ -291,7 +296,12 @@ void * task_c (void *arg)
> > rtems_test_exit(0);
> >   }
> >   if (! _Timespec_Equal_to( _value, _period) ){
> > -   perror ("Error in Task C timer_gettime\n");
> > +   fprintf(
> > +   stderr, "Error in Task A timer_gettime:\n"
> > +   "  re-armed timer: %" PRIdtime_t ":%ld does not match
> interval: %" PRIdtime_t ":%ld\n",
> > +   timerdata.it_value.tv_sec, timerdata.it_value.tv_nsec,
> > +   my_period.tv_sec, my_period.tv_nsec
> > +   );
> >   }
> >   pthread_mutex_lock ();
> >   while (data.updated == FALSE) {
> > --
> > 2.11.0
> >
> > ___
> > 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: Coverage support for tester

[Joel Sherrill]

On Wed, May 30, 2018 at 12:25 PM, Cillian O'Donnell 
wrote:

>
>
> 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.
>>>
>>
Yes. With some top level "index.html" or similar to guide you through the
subdirectories.
The entire set of subdirectories is a single "run". One use is to provide
coverage reports
for a few BSPs as part of making a release.




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

I agree with Gedare on it may be over-squashed but that may be the only way
to get it all
merged at this point. You are the third student to work on this. It is
likely changes on top
of changes on top of K's original work.

If it can't be broken apart by author, then be careful to make sure the git
log
messages indicates the authors.  Unfortunately, git doesn't appear to
handle this
well/at all and there is suggested tag here.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=451880



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

>>>
Please start a new thread on devel@ with this. I don't think it needs much
context for Gedare but the discussion should be part of the public record.



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

Re: Coverage support for tester

[Vijay Kumar Banerjee]

On 30 May 2018 at 22:55, Cillian O'Donnell  wrote:

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

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

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

buffer overrun in rtems_rfs_bitmap_create_search()

[Walter Lee]

Hi.  I am encountering a buffer overrun in
rtems_rfs_bitmap_create_search().  It seems that whenever the bitmap
uses the last bit of its search_map (i.e. (control->size + 31) % 32 ==
32)), the loop will write to the word one beyond the end of
search_map.

I filed a bug at https://devel.rtems.org/ticket/3439, with a patch
that fixes the problem.

Please let me know if I'm missing something, and if not what I need to
do to get this fixed.

Thanks,

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

Re: [PATCH] Generate coverage analysis Report

[Gedare Bloom]

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.

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

Re: Coverage support for tester

[Vijay Kumar Banerjee]

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.

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

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

[PATCH] Generate coverage analysis Report

[thelunatic]

+ 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

Co-author : Cillian O'Donnel 
---
 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)
+# 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)
+if len(self.branches_uncovered) > 0 and len(self.branches_total) > 0:
+self.percentage_branches_covered = \
+1 - (float(self.branches_uncovered) / float(self.branches_total))
+else:
+self.percentage_branches_covered = 0.0
+return
+
+def _get_next_with_colon(self, summary_file):
+line = summary_file.readline()
+if ':' in line:
+return line.split(':')[1].strip()
+else:
+return ''
+
+def _get_next_without_colon(self, summary_file):
+line = summary_file.readline()
+return line.strip().split(' ')[0]
+
+class 

Re: configure/make with multiple jobs error?

[Gedare Bloom]

On Wed, May 30, 2018 at 12:15 PM, Gedare Bloom  wrote:
> On Wed, May 30, 2018 at 12:10 PM, Gedare Bloom  wrote:
>> Hello all,
>>
>> I got a strange error just now with a fresh toolchain and current master.
>>
>> I did:
>> $ ../../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=erc32
>> --enable-tests
>> This was OK.
>>
>> $ make -j4
>> This errored out with:
>> checking for gawk... gawk
>> checking whether make sets $(MAKE)... yes
>> checking whether to enable maintainer-specific portions of Makefiles... no
>> checking for RTEMS_BSP... erc32
>> checking for perl... /usr/bin/perl
>> configure: error: Invalid BSP
>> configure: error:
>> ../../../../../../../../rtems/c/src/lib/libbsp/sparc/configure failed
>> for lib/libbsp/sparc
>> Makefile:731: recipe for target 'erc32' failed
>> make[2]: *** [erc32] Error 1
>> make[2]: Leaving directory '/media/gedare/Seagate Expansion
>> Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c'
>> Makefile:289: recipe for target 'all-recursive' failed
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory '/media/gedare/Seagate Expansion
>> Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c'
>> Makefile:414: recipe for target 'all-recursive' failed
>> make: *** [all-recursive] Error 1
>>

This error about Invalid BSP still occurs for me with a cleaned local
repo where I removed all the old files/directories. Maybe I missed a
change in developer workflow, but I think I am tripped a concurrency
bug in configure script still, because 'make' proceeds

>> $ make
>> This works.
>>
>
> Actually, this did not work all the way, it broke later. I think I
> have leftover files/directories in my libbsp (I haven't built since
> the cleanup/move was done) that could be causing me problems. I'll
> report back in a bit after I clean this stuff out.
>

But I still get an error eventually here, too:
make[4]: Entering directory '/media/gedare/Seagate Expansion
Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c/erc32/lib/libbsp'
Making all-am in .
Making all-am in sparc
make[5]: Entering directory '/media/gedare/Seagate Expansion
Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c/erc32/lib/libbsp/sparc'
make[5]: *** No rule to make target 'all-am'.  Stop.
make[5]: Leaving directory '/media/gedare/Seagate Expansion
Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c/erc32/lib/libbsp/sparc'
Makefile:656: recipe for target 'sparc' failed
make[4]: *** [sparc] Error 2

>> I guess there is something broken in the configure script under
>> concurrent threads. Ideas?
>>
>> Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: configure/make with multiple jobs error?

[Gedare Bloom]

On Wed, May 30, 2018 at 12:10 PM, Gedare Bloom  wrote:
> Hello all,
>
> I got a strange error just now with a fresh toolchain and current master.
>
> I did:
> $ ../../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=erc32
> --enable-tests
> This was OK.
>
> $ make -j4
> This errored out with:
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking for RTEMS_BSP... erc32
> checking for perl... /usr/bin/perl
> configure: error: Invalid BSP
> configure: error:
> ../../../../../../../../rtems/c/src/lib/libbsp/sparc/configure failed
> for lib/libbsp/sparc
> Makefile:731: recipe for target 'erc32' failed
> make[2]: *** [erc32] Error 1
> make[2]: Leaving directory '/media/gedare/Seagate Expansion
> Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c'
> Makefile:289: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory '/media/gedare/Seagate Expansion
> Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c'
> Makefile:414: recipe for target 'all-recursive' failed
> make: *** [all-recursive] Error 1
>
> $ make
> This works.
>

Actually, this did not work all the way, it broke later. I think I
have leftover files/directories in my libbsp (I haven't built since
the cleanup/move was done) that could be causing me problems. I'll
report back in a bit after I clean this stuff out.

> I guess there is something broken in the configure script under
> concurrent threads. Ideas?
>
> Gedare
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Updating trace buffer configuration

[Sebastian Huber]

- Am 30. Mai 2018 um 15:35 schrieb Amaan Cheval amaan.che...@gmail.com:

[...]
> Minor, but in most other places in RTEMS, I've seen pointers declared
> with the asterisk on the variable not on the type ("int *ptr;" instead
> of "int* ptr;").
[...]

The int *ptr; is RTEMS-style, the int* ptr is Chis-style and also popular in 
the C++ crowd.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

configure/make with multiple jobs error?

[Gedare Bloom]

Hello all,

I got a strange error just now with a fresh toolchain and current master.

I did:
$ ../../rtems/configure --target=sparc-rtems5 --enable-rtemsbsp=erc32
--enable-tests
This was OK.

$ make -j4
This errored out with:
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for RTEMS_BSP... erc32
checking for perl... /usr/bin/perl
configure: error: Invalid BSP
configure: error:
../../../../../../../../rtems/c/src/lib/libbsp/sparc/configure failed
for lib/libbsp/sparc
Makefile:731: recipe for target 'erc32' failed
make[2]: *** [erc32] Error 1
make[2]: Leaving directory '/media/gedare/Seagate Expansion
Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c'
Makefile:289: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/media/gedare/Seagate Expansion
Drive/work/rtems/builds/b-erc32-5/sparc-rtems5/c'
Makefile:414: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

$ make
This works.

I guess there is something broken in the configure script under
concurrent threads. Ideas?

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

Re: [GSOC] CTF generator configuration files

[Sebastian Huber]

- Am 30. Mai 2018 um 13:40 schrieb Vidushi Vashishth reachv...@gmail.com:

> Thats alright no problem! I will begin work on the documentation.

Ok, good. I am a lazy person and need your documentation to get started. I 
should be able to reproduce your stuff easily using the new documentation in 
the user manual.

The phase 1 evaluation phase begins June 11. Up to now you basically delivered 
only one simple patch and a blog post. You should try to make your work more 
visible. It is not good to silently work one week and then say that you hand 
some problems here and there. If there are problems which are not solved in two 
days, then ask for help on the mailing list.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2] Updating trace buffer configuration

[Sebastian Huber]

This patch doesn't apply. Please generate patches against the upstream master 
and not one of your local branches.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/1] Fix and extend error message in posix timer test

[Gedare Bloom]

This looks fine to me, and I'll commit after I can test it. (We
currently don't apply any significance to --signed-off-by in RTEMS
Project.) I'm investigating your inquiry on the 0/1 cover letter.

On Tue, May 15, 2018 at 5:21 AM, Martin Erik Werner
 wrote:
> _Timespec_Equal_to() does not set errno, hence avoid using perror(),
> instead use fprintf() to stderr, and extend the error message to provide
> information about what the error is (measured timer value after
> re-arming is not equal to the configured interval), and how large of a
> difference was measured.
>
> Signed-off-by: Martin Erik Werner 
> ---
>  testsuites/psxtests/psxtimer01/psxtimer.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/testsuites/psxtests/psxtimer01/psxtimer.c 
> b/testsuites/psxtests/psxtimer01/psxtimer.c
> index 032e9f8e6c..6ec049ac54 100644
> --- a/testsuites/psxtests/psxtimer01/psxtimer.c
> +++ b/testsuites/psxtests/psxtimer01/psxtimer.c
> @@ -143,7 +143,12 @@ void * task_a (void *arg)
> rtems_test_exit(0);
>   }
>   if (! _Timespec_Equal_to( _value, _period )){
> -   perror ("Error in Task A timer_gettime\n");
> +   fprintf(
> +   stderr, "Error in Task A timer_gettime:\n"
> +   "  re-armed timer: %" PRIdtime_t ":%ld does not match interval: 
> %" PRIdtime_t ":%ld\n",
> +   timerdata.it_value.tv_sec, timerdata.it_value.tv_nsec,
> +   my_period.tv_sec, my_period.tv_nsec
> +  );
>   }
>   clock = time(NULL);
>   printf("Executing task A with count = %2i %s", params->count, 
> ctime());
> @@ -291,7 +296,12 @@ void * task_c (void *arg)
> rtems_test_exit(0);
>   }
>   if (! _Timespec_Equal_to( _value, _period) ){
> -   perror ("Error in Task C timer_gettime\n");
> +   fprintf(
> +   stderr, "Error in Task A timer_gettime:\n"
> +   "  re-armed timer: %" PRIdtime_t ":%ld does not match interval: 
> %" PRIdtime_t ":%ld\n",
> +   timerdata.it_value.tv_sec, timerdata.it_value.tv_nsec,
> +   my_period.tv_sec, my_period.tv_nsec
> +   );
>   }
>   pthread_mutex_lock ();
>   while (data.updated == FALSE) {
> --
> 2.11.0
>
> ___
> 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: Coverage support for tester

[Vijay Kumar Banerjee]

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.

Any advice on how should it be approached ?

> 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
> > >
> > >  >
> > >
> > > (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.
>  That is why a few years ago, I pushed hard to reduce the complexity of
>  inline methods because we got test patch explosion when an inlined
>  method
>  included complex conditionals.
> 
>  Similarly, I think it would be helpful to coverage and verification
>  efforts to
>  follow the **shudder** MISRA rule which want you to write simple
>  conditional
>  expressions rather than compound ones. I have taken to writing code
> this
>  way as much as possible. But haven't pushed it as a coding rule.
> 
>    if (a) {
>  if (b) {
>    do x;
>  }
>   }
> 
>  Versus
>    if (a && b) {
>  do x;
>    }
> 
>  The reason is that the first is easier to analyse coverage on.
> 
>  [1] We both expect LTO could change this.
> 
>  [2] ESA did specifically mention this one though. Also in general
> terms,
>  an RTEMS Project response to MISRA rules. Which ones we follow,
>  reject, etc.. But I refuse to adopt hard rules which can't be enforced
>  by free open source tools.
> 
> >
> 

[PATCH v2] Updating trace buffer configuration

[Vidushi Vashishth]

---
 linkers/rtld-trace-buffer.ini | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/linkers/rtld-trace-buffer.ini b/linkers/rtld-trace-buffer.ini
index ee68d55..c17f2f1 100644
--- a/linkers/rtld-trace-buffer.ini
+++ b/linkers/rtld-trace-buffer.ini
@@ -27,6 +27,7 @@ header = "#include "
 header = "#include "
 header = "#include "
 header = "#include "
+header = "#include "
 
 [trace-buffer-tracers]
 code = <

Re: Coverage support for tester

[Gedare Bloom]

Hello Vijay,

Do you expect/need an answer to something in here?

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
> >
> > 
> >
> > (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.
 That is why a few years ago, I pushed hard to reduce the complexity of
 inline methods because we got test patch explosion when an inlined
 method
 included complex conditionals.

 Similarly, I think it would be helpful to coverage and verification
 efforts to
 follow the **shudder** MISRA rule which want you to write simple
 conditional
 expressions rather than compound ones. I have taken to writing code this
 way as much as possible. But haven't pushed it as a coding rule.

   if (a) {
 if (b) {
   do x;
 }
  }

 Versus
   if (a && b) {
 do x;
   }

 The reason is that the first is easier to analyse coverage on.

 [1] We both expect LTO could change this.

 [2] ESA did specifically mention this one though. Also in general terms,
 an RTEMS Project response to MISRA rules. Which ones we follow,
 reject, etc.. But I refuse to adopt hard rules which can't be enforced
 by free open source tools.

>
>
> The DWARF data provides details about the PC low and PC high of what is
> called
> concrete functions and then it provides the details about inlines.


 We don't (currently) report on the inlines as independent methods.

>
>
> >
> > 2. coverage used to feed ini file for each symbol to covoar
> > in a loop and store the result in a separate directory
> > for each symbol . Which is needed no more needed as
> > covoar can now process multi sets from a
> >  single ini file. I think the results from covoar should be
> > store in a separate directory for each symbol
> > example :- score/
> >
> >
> > A bit of history will help 

Re: [PATCH] Updating trace buffer configuration

[Gedare Bloom]

Vidushi,

For revisions to patches, please use the "-v" option for
git-format-patch before you git-send-email the patch files to append a
version number, in this case, use
git format-patch -v 2 HEAD^ -o ../
to generate a patch from the head commit in the parent directory
having the "v2" appended to it.

https://devel.rtems.org/wiki/Developer/Git/Users#CreatingaPatch

Gedare

On Wed, May 30, 2018 at 10:41 AM, Vidushi Vashishth  wrote:
> ---
>  linkers/rtld-trace-buffer.ini | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/linkers/rtld-trace-buffer.ini b/linkers/rtld-trace-buffer.ini
> index ee68d55..c17f2f1 100644
> --- a/linkers/rtld-trace-buffer.ini
> +++ b/linkers/rtld-trace-buffer.ini
> @@ -27,6 +27,7 @@ header = "#include "
>  header = "#include "
>  header = "#include "
>  header = "#include "
> +header = "#include "
>
>  [trace-buffer-tracers]
>  code = << @@ -85,7 +86,7 @@ static inline uint32_t __rtld_tbg_executing_id(void)
>  static inline uint32_t __rtld_tbg_executing_status(void)
>  {
>/* @fixme Add the current CPU for SMP. */
> -  struct _Thread_Control* tc = _Thread_Get_executing();
> +  Thread_Control* tc = _Thread_Get_executing();
>return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
>  }
>
> --
> 2.7.4
>
>
> On Wed, May 30, 2018 at 7:24 PM, Vidushi Vashishth 
> wrote:
>>
>> >Based on this error, I believe you need to drop the "struct", given
>> >that Thread_Control is the typedef for "struct _Thread_Control".
>>
>> Oh yes you are right. It was originally written with the "struct" so I
>> somehow overlooked it. I tired it this way. It works thanks.
>>
>> >Minor, but in most other places in RTEMS, I've seen pointers declared
>> >with the asterisk on the variable not on the type ("int *ptr;" instead
>> >of "int* ptr;").
>>
>> The trace linker code was last updated couple of years ago and this isn't
>> the convention used in it. I don't know if the convention has changed but I
>> stuck with how it was done in the configuration files of the trace linker.
>>
>> On Wed, May 30, 2018 at 7:05 PM, Amaan Cheval 
>> wrote:
>>>
>>> On Wed, May 30, 2018 at 6:33 PM, Vidushi Vashishth 
>>> wrote:
>>> > Could you please change the
>>> >
>>> > struct _Thread_Control
>>> >
>>> > to
>>> >
>>> > Thread_Control
>>> >
>>> > and check if it still works.
>>> >
>>> > In RTEMS, we use typedefs for structures in general.
>>> >
>>> > I tried to include the threadq.h header file so that I could use the
>>> > variable Thread_Control instead of _Thread_Control. This header file
>>> > has the
>>> > following typedef statement:
>>> >
>>> > typedef struct _Thread_Control Thread_Control;
>>> >
>>> > However this leads to the following error:
>>> >
>>> > fileio-wrapper.c:389:31: warning: initialization from incompatible
>>> > pointer
>>> > type [-Wincompatible-pointer-types]
>>> >struct Thread_Control* tc = _Thread_Get_executing();
>>> >^
>>>
>>> Based on this error, I believe you need to drop the "struct", given
>>> that Thread_Control is the typedef for "struct _Thread_Control".
>>>
>>> Minor, but in most other places in RTEMS, I've seen pointers declared
>>> with the asterisk on the variable not on the type ("int *ptr;" instead
>>> of "int* ptr;").
>>>
>>> > fileio-wrapper.c:390:32: warning: passing argument 1 of
>>> > '_Thread_Get_priority' from incompatible pointer type
>>> > [-Wincompatible-pointer-types]
>>> >return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
>>> >
>>> > I had tried this earlier too. So it doesn't work.
>>> >
>>> >
>>> >
>>> > On Wed, May 30, 2018 at 10:59 AM, Sebastian Huber
>>> >  wrote:
>>> >>
>>> >>
>>> >>
>>> >> On 29/05/18 17:36, Vidushi Vashishth wrote:
>>> >>>
>>> >>> ---
>>> >>>   linkers/rtld-trace-buffer.ini | 5 +++--
>>> >>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>> >>>
>>> >>> diff --git a/linkers/rtld-trace-buffer.ini
>>> >>> b/linkers/rtld-trace-buffer.ini
>>> >>> index af9fc31..ee68d55 100644
>>> >>> --- a/linkers/rtld-trace-buffer.ini
>>> >>> +++ b/linkers/rtld-trace-buffer.ini
>>> >>> @@ -26,6 +26,7 @@ buffer-local = " uint8_t* in;"
>>> >>>   header = "#include "
>>> >>>   header = "#include "
>>> >>>   header = "#include "
>>> >>> +header = "#include "
>>> >>> [trace-buffer-tracers]
>>> >>>   code = <<>> >>> @@ -84,8 +85,8 @@ static inline uint32_t
>>> >>> __rtld_tbg_executing_id(void)
>>> >>>   static inline uint32_t __rtld_tbg_executing_status(void)
>>> >>>   {
>>> >>> /* @fixme Add the current CPU for SMP. */
>>> >>> -  struct Thread_Control* tc = _Thread_Get_executing();
>>> >>
>>> >>
>>> >> Could you please change the
>>> >>
>>> >> struct _Thread_Control
>>> >>
>>> >> to
>>> >>
>>> >> Thread_Control
>>> >>
>>> >> and check if it still works.
>>> >>
>>> >> In RTEMS, we use typedefs for structures in general.
>>> >>
>>> >>> -  return (tc->current_priority << 8) | tc->real_priority;
>>> >>> +  struct _Thread_Control* tc = 

Re: [PATCH] Updating trace buffer configuration

[Vidushi Vashishth]

---
 linkers/rtld-trace-buffer.ini | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/linkers/rtld-trace-buffer.ini b/linkers/rtld-trace-buffer.ini
index ee68d55..c17f2f1 100644
--- a/linkers/rtld-trace-buffer.ini
+++ b/linkers/rtld-trace-buffer.ini
@@ -27,6 +27,7 @@ header = "#include "
 header = "#include "
 header = "#include "
 header = "#include "
+header = "#include "

 [trace-buffer-tracers]
 code = < >Based on this error, I believe you need to drop the "struct", given
> >that Thread_Control is the typedef for "struct _Thread_Control".
>
> Oh yes you are right. It was originally written with the "struct" so I
> somehow overlooked it. I tired it this way. It works thanks.
>
> >Minor, but in most other places in RTEMS, I've seen pointers declared
> >with the asterisk on the variable not on the type ("int *ptr;" instead
> >of "int* ptr;").
>
> The trace linker code was last updated couple of years ago and this isn't
> the convention used in it. I don't know if the convention has changed but I
> stuck with how it was done in the configuration files of the trace linker.
>
> On Wed, May 30, 2018 at 7:05 PM, Amaan Cheval 
> wrote:
>
>> On Wed, May 30, 2018 at 6:33 PM, Vidushi Vashishth 
>> wrote:
>> > Could you please change the
>> >
>> > struct _Thread_Control
>> >
>> > to
>> >
>> > Thread_Control
>> >
>> > and check if it still works.
>> >
>> > In RTEMS, we use typedefs for structures in general.
>> >
>> > I tried to include the threadq.h header file so that I could use the
>> > variable Thread_Control instead of _Thread_Control. This header file
>> has the
>> > following typedef statement:
>> >
>> > typedef struct _Thread_Control Thread_Control;
>> >
>> > However this leads to the following error:
>> >
>> > fileio-wrapper.c:389:31: warning: initialization from incompatible
>> pointer
>> > type [-Wincompatible-pointer-types]
>> >struct Thread_Control* tc = _Thread_Get_executing();
>> >^
>>
>> Based on this error, I believe you need to drop the "struct", given
>> that Thread_Control is the typedef for "struct _Thread_Control".
>>
>> Minor, but in most other places in RTEMS, I've seen pointers declared
>> with the asterisk on the variable not on the type ("int *ptr;" instead
>> of "int* ptr;").
>>
>> > fileio-wrapper.c:390:32: warning: passing argument 1 of
>> > '_Thread_Get_priority' from incompatible pointer type
>> > [-Wincompatible-pointer-types]
>> >return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
>> >
>> > I had tried this earlier too. So it doesn't work.
>> >
>> >
>> >
>> > On Wed, May 30, 2018 at 10:59 AM, Sebastian Huber
>> >  wrote:
>> >>
>> >>
>> >>
>> >> On 29/05/18 17:36, Vidushi Vashishth wrote:
>> >>>
>> >>> ---
>> >>>   linkers/rtld-trace-buffer.ini | 5 +++--
>> >>>   1 file changed, 3 insertions(+), 2 deletions(-)
>> >>>
>> >>> diff --git a/linkers/rtld-trace-buffer.ini
>> >>> b/linkers/rtld-trace-buffer.ini
>> >>> index af9fc31..ee68d55 100644
>> >>> --- a/linkers/rtld-trace-buffer.ini
>> >>> +++ b/linkers/rtld-trace-buffer.ini
>> >>> @@ -26,6 +26,7 @@ buffer-local = " uint8_t* in;"
>> >>>   header = "#include "
>> >>>   header = "#include "
>> >>>   header = "#include "
>> >>> +header = "#include "
>> >>> [trace-buffer-tracers]
>> >>>   code = <<> >>> @@ -84,8 +85,8 @@ static inline uint32_t __rtld_tbg_executing_id(void)
>> >>>   static inline uint32_t __rtld_tbg_executing_status(void)
>> >>>   {
>> >>> /* @fixme Add the current CPU for SMP. */
>> >>> -  struct Thread_Control* tc = _Thread_Get_executing();
>> >>
>> >>
>> >> Could you please change the
>> >>
>> >> struct _Thread_Control
>> >>
>> >> to
>> >>
>> >> Thread_Control
>> >>
>> >> and check if it still works.
>> >>
>> >> In RTEMS, we use typedefs for structures in general.
>> >>
>> >>> -  return (tc->current_priority << 8) | tc->real_priority;
>> >>> +  struct _Thread_Control* tc = _Thread_Get_executing();
>> >>> +  return (_Thread_Get_priority(tc) << 8) |
>> tc->Real_priority.priority;
>> >>>   }
>> >>> static inline uint32_t __rtld_tbg_executing_state(void)
>> >>
>> >>
>> >> --
>> >> Sebastian Huber, embedded brains GmbH
>> >>
>> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> >> Phone   : +49 89 189 47 41-16
>> >> Fax : +49 89 189 47 41-09
>> >> E-Mail  : sebastian.hu...@embedded-brains.de
>> >> PGP : Public key available on request.
>> >>
>> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> >>
>> >> ___
>> >> 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 

Re: Coverage support for tester

[Vijay Kumar Banerjee]

On 30 May 2018 at 00:54, Joel Sherrill  wrote:

>
>
> On Tue, May 29, 2018 at 11:27 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> 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 <
 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
 > 
 >
 > (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.
>>> That is why a few years ago, I pushed hard to reduce the complexity of
>>> inline methods because we got test patch explosion when an inlined method
>>> included complex conditionals.
>>>
>>> Similarly, I think it would be helpful to coverage and verification
>>> efforts to
>>> follow the **shudder** MISRA rule which want you to write simple
>>> conditional
>>> expressions rather than compound ones. I have taken to writing code this
>>> way as much as possible. But haven't pushed it as a coding rule.
>>>
>>>   if (a) {
>>> if (b) {
>>>   do x;
>>> }
>>>  }
>>>
>>> Versus
>>>   if (a && b) {
>>> do x;
>>>   }
>>>
>>> The reason is that the first is easier to analyse coverage on.
>>>
>>> [1] We both expect LTO could change this.
>>>
>>> [2] ESA did specifically mention this one though. Also in general terms,
>>> an RTEMS Project response to MISRA rules. Which ones we follow,
>>> reject, etc.. But I refuse to adopt hard rules which can't be enforced
>>> by free open source tools.
>>>
>>>

 The DWARF data provides details about the PC low and PC high of what is
 called
 concrete functions and then it provides the details about inlines.

>>>
>>> We don't (currently) report on the inlines as independent methods.
>>>
>>>

 >
 > 2. coverage used to feed ini file for each symbol to covoar
 > in a loop and store the result in a separate directory
 > for each symbol . Which is needed no more needed as
 > covoar can now process multi sets from a
 >  single ini file. I think the results from covoar should be
 > store in a separate directory for each symbol
 > example :- score/
 >
 >
 > A bit of history will help here. Originally covoar was run against a
 single set of
 > code by the scripting framework. We would do coverage on either "core
 parts"
 > or "developmental" (e.g. nearly all non-networked code). The
 optimization was

Re: (release notes generator) Do we need to worry about attachment?

[Gedare Bloom]

On Tue, May 29, 2018 at 5:14 PM, Chris Johns  wrote:
> On 30/5/18 5:30 am, Dannie Huang wrote:
>> I am now able to grab most of needed information from ticket's page by using
>> python (like ticket id, description, comments, etc).
>
> Fantastic.
>
>> There is a place for
>> attachment on a ticket's page, do we also need to get the information of
>> attached files? If we need to, how can I implement?
>
> I suggest we include a link a reader of the Release Notes can click on. I
> suppose this means recording a link when parsing the data from the feed.
>

Usually, the attachment is a patch. If the ticket is closed, it should
mean there is a commit available correspondingly. I'm not sure what
use the attachment would be in release notes. Making it a link
shouldn't hurt anything though, I suppose.

> 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] Updating trace buffer configuration

[Vidushi Vashishth]

>Based on this error, I believe you need to drop the "struct", given
>that Thread_Control is the typedef for "struct _Thread_Control".

Oh yes you are right. It was originally written with the "struct" so I
somehow overlooked it. I tired it this way. It works thanks.

>Minor, but in most other places in RTEMS, I've seen pointers declared
>with the asterisk on the variable not on the type ("int *ptr;" instead
>of "int* ptr;").

The trace linker code was last updated couple of years ago and this isn't
the convention used in it. I don't know if the convention has changed but I
stuck with how it was done in the configuration files of the trace linker.

On Wed, May 30, 2018 at 7:05 PM, Amaan Cheval 
wrote:

> On Wed, May 30, 2018 at 6:33 PM, Vidushi Vashishth 
> wrote:
> > Could you please change the
> >
> > struct _Thread_Control
> >
> > to
> >
> > Thread_Control
> >
> > and check if it still works.
> >
> > In RTEMS, we use typedefs for structures in general.
> >
> > I tried to include the threadq.h header file so that I could use the
> > variable Thread_Control instead of _Thread_Control. This header file has
> the
> > following typedef statement:
> >
> > typedef struct _Thread_Control Thread_Control;
> >
> > However this leads to the following error:
> >
> > fileio-wrapper.c:389:31: warning: initialization from incompatible
> pointer
> > type [-Wincompatible-pointer-types]
> >struct Thread_Control* tc = _Thread_Get_executing();
> >^
>
> Based on this error, I believe you need to drop the "struct", given
> that Thread_Control is the typedef for "struct _Thread_Control".
>
> Minor, but in most other places in RTEMS, I've seen pointers declared
> with the asterisk on the variable not on the type ("int *ptr;" instead
> of "int* ptr;").
>
> > fileio-wrapper.c:390:32: warning: passing argument 1 of
> > '_Thread_Get_priority' from incompatible pointer type
> > [-Wincompatible-pointer-types]
> >return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
> >
> > I had tried this earlier too. So it doesn't work.
> >
> >
> >
> > On Wed, May 30, 2018 at 10:59 AM, Sebastian Huber
> >  wrote:
> >>
> >>
> >>
> >> On 29/05/18 17:36, Vidushi Vashishth wrote:
> >>>
> >>> ---
> >>>   linkers/rtld-trace-buffer.ini | 5 +++--
> >>>   1 file changed, 3 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/linkers/rtld-trace-buffer.ini
> >>> b/linkers/rtld-trace-buffer.ini
> >>> index af9fc31..ee68d55 100644
> >>> --- a/linkers/rtld-trace-buffer.ini
> >>> +++ b/linkers/rtld-trace-buffer.ini
> >>> @@ -26,6 +26,7 @@ buffer-local = " uint8_t* in;"
> >>>   header = "#include "
> >>>   header = "#include "
> >>>   header = "#include "
> >>> +header = "#include "
> >>> [trace-buffer-tracers]
> >>>   code = << >>> @@ -84,8 +85,8 @@ static inline uint32_t __rtld_tbg_executing_id(void)
> >>>   static inline uint32_t __rtld_tbg_executing_status(void)
> >>>   {
> >>> /* @fixme Add the current CPU for SMP. */
> >>> -  struct Thread_Control* tc = _Thread_Get_executing();
> >>
> >>
> >> Could you please change the
> >>
> >> struct _Thread_Control
> >>
> >> to
> >>
> >> Thread_Control
> >>
> >> and check if it still works.
> >>
> >> In RTEMS, we use typedefs for structures in general.
> >>
> >>> -  return (tc->current_priority << 8) | tc->real_priority;
> >>> +  struct _Thread_Control* tc = _Thread_Get_executing();
> >>> +  return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
> >>>   }
> >>> static inline uint32_t __rtld_tbg_executing_state(void)
> >>
> >>
> >> --
> >> Sebastian Huber, embedded brains GmbH
> >>
> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> >> Phone   : +49 89 189 47 41-16
> >> Fax : +49 89 189 47 41-09
> >> E-Mail  : sebastian.hu...@embedded-brains.de
> >> PGP : Public key available on request.
> >>
> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >>
> >> ___
> >> 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: [PATCH] c-user: Fix rtems_region_create() return status

[Joel Sherrill]

On Wed, May 30, 2018 at 8:29 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 30/05/18 14:13, Joel Sherrill wrote:
>
>> Why is improperly aligned not an error?
>>
>
> _Heap_Initialize() will align it. It fails only if the area is too small.


Then there should be a note in region create to indicate that.

>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germa
> 
> ny
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Updating trace buffer configuration

[Amaan Cheval]

On Wed, May 30, 2018 at 6:33 PM, Vidushi Vashishth  wrote:
> Could you please change the
>
> struct _Thread_Control
>
> to
>
> Thread_Control
>
> and check if it still works.
>
> In RTEMS, we use typedefs for structures in general.
>
> I tried to include the threadq.h header file so that I could use the
> variable Thread_Control instead of _Thread_Control. This header file has the
> following typedef statement:
>
> typedef struct _Thread_Control Thread_Control;
>
> However this leads to the following error:
>
> fileio-wrapper.c:389:31: warning: initialization from incompatible pointer
> type [-Wincompatible-pointer-types]
>struct Thread_Control* tc = _Thread_Get_executing();
>^

Based on this error, I believe you need to drop the "struct", given
that Thread_Control is the typedef for "struct _Thread_Control".

Minor, but in most other places in RTEMS, I've seen pointers declared
with the asterisk on the variable not on the type ("int *ptr;" instead
of "int* ptr;").

> fileio-wrapper.c:390:32: warning: passing argument 1 of
> '_Thread_Get_priority' from incompatible pointer type
> [-Wincompatible-pointer-types]
>return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
>
> I had tried this earlier too. So it doesn't work.
>
>
>
> On Wed, May 30, 2018 at 10:59 AM, Sebastian Huber
>  wrote:
>>
>>
>>
>> On 29/05/18 17:36, Vidushi Vashishth wrote:
>>>
>>> ---
>>>   linkers/rtld-trace-buffer.ini | 5 +++--
>>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/linkers/rtld-trace-buffer.ini
>>> b/linkers/rtld-trace-buffer.ini
>>> index af9fc31..ee68d55 100644
>>> --- a/linkers/rtld-trace-buffer.ini
>>> +++ b/linkers/rtld-trace-buffer.ini
>>> @@ -26,6 +26,7 @@ buffer-local = " uint8_t* in;"
>>>   header = "#include "
>>>   header = "#include "
>>>   header = "#include "
>>> +header = "#include "
>>> [trace-buffer-tracers]
>>>   code = <<>> @@ -84,8 +85,8 @@ static inline uint32_t __rtld_tbg_executing_id(void)
>>>   static inline uint32_t __rtld_tbg_executing_status(void)
>>>   {
>>> /* @fixme Add the current CPU for SMP. */
>>> -  struct Thread_Control* tc = _Thread_Get_executing();
>>
>>
>> Could you please change the
>>
>> struct _Thread_Control
>>
>> to
>>
>> Thread_Control
>>
>> and check if it still works.
>>
>> In RTEMS, we use typedefs for structures in general.
>>
>>> -  return (tc->current_priority << 8) | tc->real_priority;
>>> +  struct _Thread_Control* tc = _Thread_Get_executing();
>>> +  return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
>>>   }
>>> static inline uint32_t __rtld_tbg_executing_state(void)
>>
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : +49 89 189 47 41-16
>> Fax : +49 89 189 47 41-09
>> E-Mail  : sebastian.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>> ___
>> 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: [PATCH] c-user: Fix rtems_region_create() return status

[Sebastian Huber]

On 30/05/18 14:13, Joel Sherrill wrote:

Why is improperly aligned not an error?


_Heap_Initialize() will align it. It fails only if the area is too small.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [PATCH] Updating trace buffer configuration

[Vidushi Vashishth]

Could you please change the

struct _Thread_Control

to

Thread_Control

and check if it still works.

In RTEMS, we use typedefs for structures in general.

I tried to include the threadq.h header file so that I could use the
variable Thread_Control instead of _Thread_Control. This header file has
the following typedef statement:

*typedef struct _Thread_Control Thread_Control;*

However this leads to the following error:







*fileio-wrapper.c:389:31: warning: initialization from incompatible pointer
type [-Wincompatible-pointer-types]   struct Thread_Control* tc =
_Thread_Get_executing();
^fileio-wrapper.c:390:32: warning: passing argument 1
of '_Thread_Get_priority' from incompatible pointer type
[-Wincompatible-pointer-types]   return (_Thread_Get_priority(tc) << 8) |
tc->Real_priority.priority;*
I had tried this earlier too. So it doesn't work.



On Wed, May 30, 2018 at 10:59 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 29/05/18 17:36, Vidushi Vashishth wrote:
>
>> ---
>>   linkers/rtld-trace-buffer.ini | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/linkers/rtld-trace-buffer.ini b/linkers/rtld-trace-buffer.in
>> i
>> index af9fc31..ee68d55 100644
>> --- a/linkers/rtld-trace-buffer.ini
>> +++ b/linkers/rtld-trace-buffer.ini
>> @@ -26,6 +26,7 @@ buffer-local = " uint8_t* in;"
>>   header = "#include "
>>   header = "#include "
>>   header = "#include "
>> +header = "#include "
>> [trace-buffer-tracers]
>>   code = <<> @@ -84,8 +85,8 @@ static inline uint32_t __rtld_tbg_executing_id(void)
>>   static inline uint32_t __rtld_tbg_executing_status(void)
>>   {
>> /* @fixme Add the current CPU for SMP. */
>> -  struct Thread_Control* tc = _Thread_Get_executing();
>>
>
> Could you please change the
>
> struct _Thread_Control
>
> to
>
> Thread_Control
>
> and check if it still works.
>
> In RTEMS, we use typedefs for structures in general.
>
> -  return (tc->current_priority << 8) | tc->real_priority;
>> +  struct _Thread_Control* tc = _Thread_Get_executing();
>> +  return (_Thread_Get_priority(tc) << 8) | tc->Real_priority.priority;
>>   }
>> static inline uint32_t __rtld_tbg_executing_state(void)
>>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> 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] c-user: Fix rtems_region_create() return status

[Joel Sherrill]

Why is improperly aligned not an error?

On Wed, May 30, 2018, 3:53 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  c-user/region_manager.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/c-user/region_manager.rst b/c-user/region_manager.rst
> index 1bebd8a..713fb07 100644
> --- a/c-user/region_manager.rst
> +++ b/c-user/region_manager.rst
> @@ -255,12 +255,13 @@ DIRECTIVE STATUS CODES:
> - ``id`` is NULL
>   * - ``RTEMS_INVALID_ADDRESS``
> - ``starting_address`` is NULL
> - * - ``RTEMS_INVALID_ADDRESS``
> -   - address not on four byte boundary
>   * - ``RTEMS_TOO_MANY``
> - too many regions created
>   * - ``RTEMS_INVALID_SIZE``
> - invalid page size
> + * - ``RTEMS_INVALID_SIZE``
> +   - the memory area defined by the starting address and the length
> + parameters is too small
>
>  DESCRIPTION:
>  This directive creates a region from a physically contiguous memory
> space
> --
> 2.13.6
>
> ___
> 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] beagle: Disable WiFi if libbsd is build without it.

[Udit agarwal]

Hi,
Thanks, that patch worked perfectly. Wifi is now, by default disabled.

Regards,
Udit agarwal

On Wed, May 30, 2018 at 5:04 PM, Christian Mauderer <
christian.maude...@embedded-brains.de> wrote:

> Update #3351.
> ---
>  rtemsbsd/include/bsp/nexus-devices.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/rtemsbsd/include/bsp/nexus-devices.h
> b/rtemsbsd/include/bsp/nexus-devices.h
> index 13d51ceb..f7003923 100644
> --- a/rtemsbsd/include/bsp/nexus-devices.h
> +++ b/rtemsbsd/include/bsp/nexus-devices.h
> @@ -37,6 +37,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>
>
> @@ -58,6 +59,7 @@ SYSINIT_DRIVER_REFERENCE(usbss, simplebus);
>  SYSINIT_DRIVER_REFERENCE(musbotg, usbss);
>  SYSINIT_DRIVER_REFERENCE(sdhci_ti, simplebus);
>  SYSINIT_DRIVER_REFERENCE(mmcsd, mmc);
> +#ifdef RTEMS_BSD_MODULE_IEEE80211
>  SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
>  SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
>  SYSINIT_MODULE_REFERENCE(wlan_sta);
> @@ -66,6 +68,7 @@ SYSINIT_MODULE_REFERENCE(wlan_wep);
>  SYSINIT_MODULE_REFERENCE(wlan_tkip);
>  SYSINIT_MODULE_REFERENCE(wlan_ccmp);
>  SYSINIT_REFERENCE(rtwn_rtl8188eufw);
> +#endif /* RTEMS_BSD_MODULE_IEEE80211 */
>
>  RTEMS_BSD_DRIVER_USB;
>  RTEMS_BSD_DRIVER_USB_MASS;
> --
> 2.13.6
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSOC] CTF generator configuration files

[Vidushi Vashishth]

Thats alright no problem! I will begin work on the documentation.



On Wed, May 30, 2018 at 4:59 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 30/05/18 13:27, Vidushi Vashishth wrote:
>
>> Hi Sebastian!
>>
>> Yes I have been working on the documentation. I wrote a blog about the
>> the tracing framework use cases a while ago. It can be seen here
>> https://vidushivashishth.github.io/Third-post-copy/
>> I will write a blog about trace buffer generation which would explain all
>> the questions you have posed too. As suggested by Gedare the blog posts
>> will somewhat be the first draft of what is to go in the user manual. I
>> would appreciate your feedback on the blogpost.
>>
>
> I would highly appreciate if you do this not in a blog. The primary medium
> for RTEMS development is this mailing list. Please start with a skeleton
> structure for this new stuff in the user manual and send patches to the
> mailing list for review.
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] beagle: Disable WiFi if libbsd is build without it.

[Christian Mauderer]

Update #3351.
---
 rtemsbsd/include/bsp/nexus-devices.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 13d51ceb..f7003923 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -37,6 +37,7 @@
 #include 
 
 #include 
+#include 
 #include 
 
 
@@ -58,6 +59,7 @@ SYSINIT_DRIVER_REFERENCE(usbss, simplebus);
 SYSINIT_DRIVER_REFERENCE(musbotg, usbss);
 SYSINIT_DRIVER_REFERENCE(sdhci_ti, simplebus);
 SYSINIT_DRIVER_REFERENCE(mmcsd, mmc);
+#ifdef RTEMS_BSD_MODULE_IEEE80211
 SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
 SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
 SYSINIT_MODULE_REFERENCE(wlan_sta);
@@ -66,6 +68,7 @@ SYSINIT_MODULE_REFERENCE(wlan_wep);
 SYSINIT_MODULE_REFERENCE(wlan_tkip);
 SYSINIT_MODULE_REFERENCE(wlan_ccmp);
 SYSINIT_REFERENCE(rtwn_rtl8188eufw);
+#endif /* RTEMS_BSD_MODULE_IEEE80211 */
 
 RTEMS_BSD_DRIVER_USB;
 RTEMS_BSD_DRIVER_USB_MASS;
-- 
2.13.6

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

Re: [GSOC] CTF generator configuration files

[Sebastian Huber]

On 30/05/18 13:27, Vidushi Vashishth wrote:

Hi Sebastian!

Yes I have been working on the documentation. I wrote a blog about the 
the tracing framework use cases a while ago. It can be seen here 
https://vidushivashishth.github.io/Third-post-copy/
I will write a blog about trace buffer generation which would explain 
all the questions you have posed too. As suggested by Gedare the blog 
posts will somewhat be the first draft of what is to go in the user 
manual. I would appreciate your feedback on the blogpost.


I would highly appreciate if you do this not in a blog. The primary 
medium for RTEMS development is this mailing list. Please start with a 
skeleton structure for this new stuff in the user manual and send 
patches to the mailing list for review.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

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

Re: [GSOC] CTF generator configuration files

[Vidushi Vashishth]

Hi Sebastian!

Yes I have been working on the documentation. I wrote a blog about the the
tracing framework use cases a while ago. It can be seen here
https://vidushivashishth.github.io/Third-post-copy/
I will write a blog about trace buffer generation which would explain all
the questions you have posed too. As suggested by Gedare the blog posts
will somewhat be the first draft of what is to go in the user manual. I
would appreciate your feedback on the blogpost.

Thanks!

On Wed, May 30, 2018 at 11:03 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Vidushi,
>
> could you please also work on the user documentation and the use cases. I
> am not an expert in this CTF stuff. Without an introduction in the user
> manual I am pretty helpless. I don't know which tools I have to install. I
> don't know the workflow. I don't know why I need a "CTF generator
> configuration file". I have no time to read all the documents here and
> there. Users have no time and are impatient.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> 
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC] Ways to make the x86_64 port work with UEFI

[Amaan Cheval]

On Wed, May 30, 2018 at 4:30 AM, Joel Sherrill  wrote:
>
>
> On Tue, May 29, 2018 at 11:26 AM, Amaan Cheval 
> wrote:
>>
>> On Tue, May 29, 2018 at 9:28 PM, Amaan Cheval 
>> wrote:
>> > Noted, thanks a ton for the details! Unrelated to the topic at hand,
>> > but out of interest, is this the only reading material for further
>> > details? http://ceur-ws.org/Vol-1697/EWiLi16_12.pdf
>> >
>> > In brief: My tests for keeping a libfake.a (compiled without -fpic)
>> > and a loader.so with a user-appXYZ.c have been successful, but I'm not
>> > sure if my assumptions hold for all cases. See the details below for
>> > more.
>> >
>> > Next actions:
>> > - Read more of Linkers and Loaders since it seems to be the only
>> > detailed resource I've found at this point
>> > - Experiment with actually using the existing librtems*.a I've got and
>> > making them boot as a PE UEFI application image
>> >
>> >
>> > 
>> >
>> > In more detail:
>> >
>> > The problem:
>> > That UEFI needs a relocatable PE file, i.e. one that can function
>> > regardless of the physical address it's loaded at (no virtual
>> > addresses that early).
>> > To build an ELF of that kind, the resources I've seen all build their
>> > source with -fpic, and then use objcopy to convert the ELF into a
>> > relocatable PE, with an embedded runtime self-relocator (akin to
>> > load-time relocation, if I'm understanding correctly).
>> >
>> > What Joel suggested seems to be the simplest option - see if not using
>> > -fpic for _all_ of RTEMS' build system is fine. I think it might be
>> > from some testing, but I'm not sure if this is conclusive since I need
>> > to understand the specifics of the entire development process better.
>> >
>> > So here's my understanding of the situation at the moment:
>> >
>> > - librtems*.a is made up of object files, compiled without -fpic, and
>> > that should be fine because I believe object files will use RIP
>> > relative addressing code by default on x64 where it can, and leave the
>> > rest for link-time relocations to handle. IF this is true, this works
>> > perfectly for us because all memory accesses and jumps/calls are
>> > relative.
>
>
> Just to be clear. For Deos, I am compiling all code with -fPIC. This
> includes all librtemscpu.a and librtemsbsp.a. When I accidentally
> missed an adapter file, that caused an issue.
>

Oh my, that's me misreading majorly, sorry about that. I'm still
unclear on how this works:

> Unless the loader forces something, you can use PIC with no build system 
> changes.

I meant that to build with fpic for x86_64/amd64 and nothing else,
we'd end up having to add a lot of special cases within the build
system for even the "generic" parts of RTEMS, such as what's in cpukit
(all the subdirs except cpukit/score/cpu), right? My concern was that
in doing this, the already overcomplicated build system gets more
complicated. If y'all don't think that kind of "if amd64, then use
-fPIC" logic feels hacky, I'm okay with this approach 100%, and we can
work to find a way to make that special-casing as explicit as
possible.

>>
>> >
>> > - We can have a loader.c which acts as the core with the efi_main
>> > function - compile it with -fpic into loader.so, and then link
>> > loader.so, librtems*.a, and user-appXYZ.c together to form a
>> > relocatable ELF, then convert it into a PE using objcopy. Note that
>> > from what I can tell, the ELF generated from this still has type EXEC,
>> > not DYN, according to readelf.
>>
>> Correction: This was a leftover file that I'd forgotten to take out
>> after renaming a target. Sorry about the confusion. Just using the
>> "-shared" flag does cause the resulting ELF to be of type DYN.
>>
>> >
>> > The concerns I have are about my assumptions; if GCC generates any
>> > code that uses absolute addressing and that is resolved as a link-time
>> > relocation, that could be problematic because the final relocatable PE
>> > may not match up with the resolved absolute address.
>
>
> The Deos kernel guys had me check readelf on a known good executable
> with the ones I was producing. The loadable sections should match up.
> For example, on one architecture I missed an alignment in the linkcmds
> and on another, an argument hidden in bsp_specs made a section writable
> which should have been read-only. Just check what you can with readelf
> and objdump section headers.
>
>>
>> >
>> > My tests with a fake static archive library, and creating a PE have
>> > been successful, but I'm unsure of how to trigger the relocation
>> > behavior by the UEFI firmware (i.e. loading the UEFI image at an
>> > address other than it's preferred one). One idea is to have a UEFI
>> > application image that loads this test UEFI application image through
>> > the "LoadImage" function UEFI provides as a service and then to use
>> > QEMU's monitor / gdb inspection capabilities to see if the address the
>> > image is 

[PATCH] c-user: Fix rtems_region_create() return status

[Sebastian Huber]

---
 c-user/region_manager.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/c-user/region_manager.rst b/c-user/region_manager.rst
index 1bebd8a..713fb07 100644
--- a/c-user/region_manager.rst
+++ b/c-user/region_manager.rst
@@ -255,12 +255,13 @@ DIRECTIVE STATUS CODES:
- ``id`` is NULL
  * - ``RTEMS_INVALID_ADDRESS``
- ``starting_address`` is NULL
- * - ``RTEMS_INVALID_ADDRESS``
-   - address not on four byte boundary
  * - ``RTEMS_TOO_MANY``
- too many regions created
  * - ``RTEMS_INVALID_SIZE``
- invalid page size
+ * - ``RTEMS_INVALID_SIZE``
+   - the memory area defined by the starting address and the length
+ parameters is too small
 
 DESCRIPTION:
 This directive creates a region from a physically contiguous memory space
-- 
2.13.6

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