Re: Improve coverage analysis toolset

[Cillian O'Donnell]

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

Start a new thread for this issue like Chris mentioned.

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

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

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

On 3 April 2018 at 03:58, Chris Johns  wrote:

> On 03/04/2018 02:10, Cillian O'Donnell wrote:
> > Sure if you want to crack at it.
> >
> > If you pull the ini-update branch again, I've included the other files
> you'll need.
> >
> > Now if you try and run rtems-test with coverage you will get
> >
> > cpod@cpod ~ $ $HOME/development/rtems/test/rtems-tools/tester/rtems-test
> > --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
> > --rtems-bsp=leon3_qemu --coverage --rtems-builddir=$HOME/
> development/rtems/leon3
> > sparc-rtems5/c/leon3/testsuites/samples
> > RTEMS Testing - Tester, 5 (80a1e6d9607e)
> > Traceback (most recent call last):
> >   File "/home/cpod/development/rtems/test/rtems-tools/tester/rtems-test",
> line
> > 40, in 
> > rt.test.run()
> >   File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py",
> line
> > 310, in run
> > coverage = coverage_get_obj(opts, path_to_builddir[1])
> >   File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py",
> line
> > 230, in coverage_get_obj
> > coverage_obj = coverage.coverage_run(opts.defaults,
> path_to_builddir)
> >   File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/
> coverage.py",
> > line 329, in __init__
> > self.config_map = self.macros.macros['coverage']
>

I managed was getting these errors yesterday after pulling the changes but
for some reason it's not working as expected , now .
It's giving the error :
 error: mandatory item not found in bsp section: bsp
where can this error be coming from ?

>
> I would not access the 'macros' dictionary directly like this. It
> circumvents
> the map support. There is '__getitem__' support on the class which is
> better but
> still raises an exception on an index error. You can ask if a key is
> present and
> the 'get()' interface returns 'None' if not found.
>
> > KeyError: 'coverage'
>
> Can we please create new threads for new topics?
>
> Thanks
> Chris
>

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

Re: Improve coverage analysis toolset

[Chris Johns]

On 03/04/2018 02:10, Cillian O'Donnell wrote:
> Sure if you want to crack at it.
> 
> If you pull the ini-update branch again, I've included the other files you'll 
> need.
> 
> Now if you try and run rtems-test with coverage you will get
> 
> cpod@cpod ~ $ $HOME/development/rtems/test/rtems-tools/tester/rtems-test
> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
> --rtems-bsp=leon3_qemu --coverage 
> --rtems-builddir=$HOME/development/rtems/leon3
> sparc-rtems5/c/leon3/testsuites/samples
> RTEMS Testing - Tester, 5 (80a1e6d9607e)
> Traceback (most recent call last):
>   File "/home/cpod/development/rtems/test/rtems-tools/tester/rtems-test", line
> 40, in 
>     rt.test.run()
>   File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py", line
> 310, in run
>     coverage = coverage_get_obj(opts, path_to_builddir[1])
>   File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py", line
> 230, in coverage_get_obj
>     coverage_obj = coverage.coverage_run(opts.defaults, path_to_builddir)
>   File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/coverage.py",
> line 329, in __init__
>     self.config_map = self.macros.macros['coverage']

I would not access the 'macros' dictionary directly like this. It circumvents
the map support. There is '__getitem__' support on the class which is better but
still raises an exception on an index error. You can ask if a key is present and
the 'get()' interface returns 'None' if not found.

> KeyError: 'coverage'

Can we please create new threads for new topics?

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

Re: Improve coverage analysis toolset

[Cillian O'Donnell]

Sure if you want to crack at it.

If you pull the ini-update branch again, I've included the other files
you'll need.

Now if you try and run rtems-test with coverage you will get

cpod@cpod ~ $ $HOME/development/rtems/test/rtems-tools/tester/rtems-test
--rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
--rtems-bsp=leon3_qemu --coverage
--rtems-builddir=$HOME/development/rtems/leon3
sparc-rtems5/c/leon3/testsuites/samples
RTEMS Testing - Tester, 5 (80a1e6d9607e)
Traceback (most recent call last):
  File "/home/cpod/development/rtems/test/rtems-tools/tester/rtems-test",
line 40, in 
rt.test.run()
  File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py",
line 310, in run
coverage = coverage_get_obj(opts, path_to_builddir[1])
  File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/test.py",
line 230, in coverage_get_obj
coverage_obj = coverage.coverage_run(opts.defaults, path_to_builddir)
  File "/home/cpod/development/rtems/test/rtems-tools/tester/rt/coverage.py",
line 329, in __init__
self.config_map = self.macros.macros['coverage']
KeyError: 'coverage'


So this is the starting point

https://github.com/cillianodonnell/rtems-tools/
blob/coverage-merge/tester/rt/coverage.py#L329

The coverage options from here

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

which was once

https://github.com/cillianodonnell/rtems-tools/blob/ini-update/tester/rtems/
testing/coverage.mc

So you'll have to dig down from coverage.py to see what needs tob e changed
to parse the new format.

Good luck.

On 2 April 2018 at 16:22, Vijay Kumar Banerjee 
wrote:

> Hello ,
>
> I'm currently going through the coverage code , Can you please help me
> understand what are the specific changes that are needed for the coverage
> to be running again?
> thanks
>
> -- vijay
>
> On 26 March 2018 at 09:30, Vijay Kumar Banerjee 
> wrote:
>
>> 1. Yes , I plan to work on identifying the discrepancies between what
>> covoar reports directly and what the gcov reports based on its gcov output.
>>
>> 2. I understand this point that the  scripting that generates symbol set
>> file, needs to be modified accordingly
>>
>> 3. I have planned to make a note and understand the requirements, changes
>> needed and the desired type of output during the community bonding period,
>> so that I have a clear picture of the objective before I start working on
>> it.
>>
>> The plan is to work on gcov after the existing work is merged.
>>  Have I planned too much to work on during the summer? Should I modify my
>> plan in some way? Please suggest .
>>
>> Thanks
>>
>> -- vijay
>>
>> On 26 March 2018 at 03:49, Joel Sherrill  wrote:
>>
>>> Just a couple of questions and planning issues. The planning issues
>>> are because the requirements for some of the work are likely not solid
>>> on our side.
>>>
>>> 1. Do you plan to work on identifying the discrepancies between
>>> what covoar reports directly and what gcov reports based on its
>>> gcov file output? I ask because I lined up someone from the GCC
>>> community who should be able to tell us what is not right once
>>> we have specific cases.
>>>
>>> 2. My recollection is that the symbol set file is generated from
>>> the RTEMS libraries under test. The scripting that generates this
>>> file will have to change also. The set of symbols changes as
>>> RTEMS evolves.
>>>
>>> 3. Chris has had ideas on changing the output from directly
>>> producing ascii and html to something else. It is on he and I
>>> to give you input on the actual format.
>>>
>>> Personally getting all existing work merged and it in a state
>>> where we can produce coverage reports again is really a
>>> critical thing. The previous work changed it from being
>>> a standalone shell script that drove things to part of the RSB
>>> and make it possible to have the reports based on subdirectories
>>> rather than one large report.
>>>
>>> I don't 'think this changes your plan except that the plan seems to
>>> put gcov as bonus work. It isn't discussed as work during the
>>> summer.It would be nice to get gcov correctness done earlier
>>> because that might be the best way to nice reports. For
>>> example, running lcov on the .gcov files produced by covoar
>>> might be an option.
>>>
>>> --joel
>>>
>>>
>>> On Sun, Mar 25, 2018 at 3:16 PM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 submitted !
 If you find time , please give final review as well.

 Thanks

 On 26 Mar 2018 1:44 a.m., "Joel Sherrill"  wrote:

> I am out and not at a computer. Someone can double check me but I
> believe you can replace the PDF you upload.
>
> Unless someone answers soon, just upload it.
>
> --joel
>
> On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" <
> vijaykumar9...@gmail.com> wrote:
>
>> It's the 

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

Hello ,

I'm currently going through the coverage code , Can you please help me
understand what are the specific changes that are needed for the coverage
to be running again?
thanks

-- vijay

On 26 March 2018 at 09:30, Vijay Kumar Banerjee 
wrote:

> 1. Yes , I plan to work on identifying the discrepancies between what
> covoar reports directly and what the gcov reports based on its gcov output.
>
> 2. I understand this point that the  scripting that generates symbol set
> file, needs to be modified accordingly
>
> 3. I have planned to make a note and understand the requirements, changes
> needed and the desired type of output during the community bonding period,
> so that I have a clear picture of the objective before I start working on
> it.
>
> The plan is to work on gcov after the existing work is merged.
>  Have I planned too much to work on during the summer? Should I modify my
> plan in some way? Please suggest .
>
> Thanks
>
> -- vijay
>
> On 26 March 2018 at 03:49, Joel Sherrill  wrote:
>
>> Just a couple of questions and planning issues. The planning issues
>> are because the requirements for some of the work are likely not solid
>> on our side.
>>
>> 1. Do you plan to work on identifying the discrepancies between
>> what covoar reports directly and what gcov reports based on its
>> gcov file output? I ask because I lined up someone from the GCC
>> community who should be able to tell us what is not right once
>> we have specific cases.
>>
>> 2. My recollection is that the symbol set file is generated from
>> the RTEMS libraries under test. The scripting that generates this
>> file will have to change also. The set of symbols changes as
>> RTEMS evolves.
>>
>> 3. Chris has had ideas on changing the output from directly
>> producing ascii and html to something else. It is on he and I
>> to give you input on the actual format.
>>
>> Personally getting all existing work merged and it in a state
>> where we can produce coverage reports again is really a
>> critical thing. The previous work changed it from being
>> a standalone shell script that drove things to part of the RSB
>> and make it possible to have the reports based on subdirectories
>> rather than one large report.
>>
>> I don't 'think this changes your plan except that the plan seems to
>> put gcov as bonus work. It isn't discussed as work during the
>> summer.It would be nice to get gcov correctness done earlier
>> because that might be the best way to nice reports. For
>> example, running lcov on the .gcov files produced by covoar
>> might be an option.
>>
>> --joel
>>
>>
>> On Sun, Mar 25, 2018 at 3:16 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> submitted !
>>> If you find time , please give final review as well.
>>>
>>> Thanks
>>>
>>> On 26 Mar 2018 1:44 a.m., "Joel Sherrill"  wrote:
>>>
 I am out and not at a computer. Someone can double check me but I
 believe you can replace the PDF you upload.

 Unless someone answers soon, just upload it.

 --joel

 On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" <
 vijaykumar9...@gmail.com> wrote:

> It's the last day before the deadline!
> Please provide a final review of the proposal before submitting.
>
> Thanks
>
> -- vijay
>
> On 24 March 2018 at 21:37, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> hello mentors and other developers of the community , there are only
>> three days remaining to the GSoC proposal submission deadline.
>>
>> I request the mentors and everyone in the community who has
>> experience in RTEMS, to please go through my proposal for Coverage 
>> Analysis
>> tool improvement project , if they have time , and suggest any kind of
>> improvements and changes .
>> here is the link to the proposal
>> https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SC
>> rLETlerxD6t0SOcQNLQ/edit?usp=sharing
>> Thank you
>>
>> -- vijay
>>
>> On 22 March 2018 at 04:30, Joel Sherrill  wrote:
>>
>>> Glad you have tests running. Hopefully as Cillian suggested, you can
>>> fix the
>>> remaining issues to see coverage.
>>>
>>> We certainly need to get this merged if Chris is OK with it and it
>>> doesn't
>>> break anything else.
>>>
>>> I am reviewing proposals now. Seems to be a queue. :)
>>>
>>> --joel
>>>
>>> On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Sir ,
 I have done the changes in the proposal , based on the comments in
 the google doc , please review it and suggest any further changes if
 required

 Thank you ,
 -- vijay

 P.S : the previous version is in parentheses , I will remove them
 after you review the changes .

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

1. Yes , I plan to work on identifying the discrepancies between what
covoar reports directly and what the gcov reports based on its gcov output.

2. I understand this point that the  scripting that generates symbol set
file, needs to be modified accordingly

3. I have planned to make a note and understand the requirements, changes
needed and the desired type of output during the community bonding period,
so that I have a clear picture of the objective before I start working on
it.

The plan is to work on gcov after the existing work is merged.
 Have I planned too much to work on during the summer? Should I modify my
plan in some way? Please suggest .

Thanks

-- vijay

On 26 March 2018 at 03:49, Joel Sherrill  wrote:

> Just a couple of questions and planning issues. The planning issues
> are because the requirements for some of the work are likely not solid
> on our side.
>
> 1. Do you plan to work on identifying the discrepancies between
> what covoar reports directly and what gcov reports based on its
> gcov file output? I ask because I lined up someone from the GCC
> community who should be able to tell us what is not right once
> we have specific cases.
>
> 2. My recollection is that the symbol set file is generated from
> the RTEMS libraries under test. The scripting that generates this
> file will have to change also. The set of symbols changes as
> RTEMS evolves.
>
> 3. Chris has had ideas on changing the output from directly
> producing ascii and html to something else. It is on he and I
> to give you input on the actual format.
>
> Personally getting all existing work merged and it in a state
> where we can produce coverage reports again is really a
> critical thing. The previous work changed it from being
> a standalone shell script that drove things to part of the RSB
> and make it possible to have the reports based on subdirectories
> rather than one large report.
>
> I don't 'think this changes your plan except that the plan seems to
> put gcov as bonus work. It isn't discussed as work during the
> summer.It would be nice to get gcov correctness done earlier
> because that might be the best way to nice reports. For
> example, running lcov on the .gcov files produced by covoar
> might be an option.
>
> --joel
>
>
> On Sun, Mar 25, 2018 at 3:16 PM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> submitted !
>> If you find time , please give final review as well.
>>
>> Thanks
>>
>> On 26 Mar 2018 1:44 a.m., "Joel Sherrill"  wrote:
>>
>>> I am out and not at a computer. Someone can double check me but I
>>> believe you can replace the PDF you upload.
>>>
>>> Unless someone answers soon, just upload it.
>>>
>>> --joel
>>>
>>> On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 It's the last day before the deadline!
 Please provide a final review of the proposal before submitting.

 Thanks

 -- vijay

 On 24 March 2018 at 21:37, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> hello mentors and other developers of the community , there are only
> three days remaining to the GSoC proposal submission deadline.
>
> I request the mentors and everyone in the community who has experience
> in RTEMS, to please go through my proposal for Coverage Analysis tool
> improvement project , if they have time , and suggest any kind of
> improvements and changes .
> here is the link to the proposal
> https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SC
> rLETlerxD6t0SOcQNLQ/edit?usp=sharing
> Thank you
>
> -- vijay
>
> On 22 March 2018 at 04:30, Joel Sherrill  wrote:
>
>> Glad you have tests running. Hopefully as Cillian suggested, you can
>> fix the
>> remaining issues to see coverage.
>>
>> We certainly need to get this merged if Chris is OK with it and it
>> doesn't
>> break anything else.
>>
>> I am reviewing proposals now. Seems to be a queue. :)
>>
>> --joel
>>
>> On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Sir ,
>>> I have done the changes in the proposal , based on the comments in
>>> the google doc , please review it and suggest any further changes if
>>> required
>>>
>>> Thank you ,
>>> -- vijay
>>>
>>> P.S : the previous version is in parentheses , I will remove them
>>> after you review the changes .
>>>
>>> On 18 March 2018 at 16:05, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Thanks Cillian :)

 It's great to see it running ,  I'll do some background reading
 about RSB, and RTEMS-Tools along with the covoar code . And also work 
 on my
 python skills.

 to try rtems-test on a bsp that runs gdb , I tried it on erc32 and

Re: Improve coverage analysis toolset

[Joel Sherrill]

Just a couple of questions and planning issues. The planning issues
are because the requirements for some of the work are likely not solid
on our side.

1. Do you plan to work on identifying the discrepancies between
what covoar reports directly and what gcov reports based on its
gcov file output? I ask because I lined up someone from the GCC
community who should be able to tell us what is not right once
we have specific cases.

2. My recollection is that the symbol set file is generated from
the RTEMS libraries under test. The scripting that generates this
file will have to change also. The set of symbols changes as
RTEMS evolves.

3. Chris has had ideas on changing the output from directly
producing ascii and html to something else. It is on he and I
to give you input on the actual format.

Personally getting all existing work merged and it in a state
where we can produce coverage reports again is really a
critical thing. The previous work changed it from being
a standalone shell script that drove things to part of the RSB
and make it possible to have the reports based on subdirectories
rather than one large report.

I don't 'think this changes your plan except that the plan seems to
put gcov as bonus work. It isn't discussed as work during the
summer.It would be nice to get gcov correctness done earlier
because that might be the best way to nice reports. For
example, running lcov on the .gcov files produced by covoar
might be an option.

--joel


On Sun, Mar 25, 2018 at 3:16 PM, Vijay Kumar Banerjee <
vijaykumar9...@gmail.com> wrote:

> submitted !
> If you find time , please give final review as well.
>
> Thanks
>
> On 26 Mar 2018 1:44 a.m., "Joel Sherrill"  wrote:
>
>> I am out and not at a computer. Someone can double check me but I believe
>> you can replace the PDF you upload.
>>
>> Unless someone answers soon, just upload it.
>>
>> --joel
>>
>> On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" 
>> wrote:
>>
>>> It's the last day before the deadline!
>>> Please provide a final review of the proposal before submitting.
>>>
>>> Thanks
>>>
>>> -- vijay
>>>
>>> On 24 March 2018 at 21:37, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 hello mentors and other developers of the community , there are only
 three days remaining to the GSoC proposal submission deadline.

 I request the mentors and everyone in the community who has experience
 in RTEMS, to please go through my proposal for Coverage Analysis tool
 improvement project , if they have time , and suggest any kind of
 improvements and changes .
 here is the link to the proposal
 https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SC
 rLETlerxD6t0SOcQNLQ/edit?usp=sharing
 Thank you

 -- vijay

 On 22 March 2018 at 04:30, Joel Sherrill  wrote:

> Glad you have tests running. Hopefully as Cillian suggested, you can
> fix the
> remaining issues to see coverage.
>
> We certainly need to get this merged if Chris is OK with it and it
> doesn't
> break anything else.
>
> I am reviewing proposals now. Seems to be a queue. :)
>
> --joel
>
> On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Sir ,
>> I have done the changes in the proposal , based on the comments in
>> the google doc , please review it and suggest any further changes if
>> required
>>
>> Thank you ,
>> -- vijay
>>
>> P.S : the previous version is in parentheses , I will remove them
>> after you review the changes .
>>
>> On 18 March 2018 at 16:05, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Thanks Cillian :)
>>>
>>> It's great to see it running ,  I'll do some background reading
>>> about RSB, and RTEMS-Tools along with the covoar code . And also work 
>>> on my
>>> python skills.
>>>
>>> to try rtems-test on a bsp that runs gdb , I tried it on erc32 and
>>> that also worked.
>>>
>>> I'm also waiting for Joel and other mentors' review on my draft
>>> proposal, so that I can also work on it and make any changes if needed.
>>>
>>> Thanks .
>>>
>>> -- vijay
>>>
>>> On 18 March 2018 at 14:17, Cillian O'Donnell 
>>> wrote:
>>>


 On 18 March 2018 at 06:47, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> It worked !
>

 That's great!  That's the good news then. I was using an old leon3
 build and maybe some older Qemu too and I think that's why I didn't 
 see any
 issues initially. I was hoping you could see the coverage running and 
 the
 reports generated from that but it looks like the full update to the
 current master will be necessary to 

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

submitted !
If you find time , please give final review as well.

Thanks

On 26 Mar 2018 1:44 a.m., "Joel Sherrill"  wrote:

> I am out and not at a computer. Someone can double check me but I believe
> you can replace the PDF you upload.
>
> Unless someone answers soon, just upload it.
>
> --joel
>
> On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" 
> wrote:
>
>> It's the last day before the deadline!
>> Please provide a final review of the proposal before submitting.
>>
>> Thanks
>>
>> -- vijay
>>
>> On 24 March 2018 at 21:37, Vijay Kumar Banerjee > > wrote:
>>
>>> hello mentors and other developers of the community , there are only
>>> three days remaining to the GSoC proposal submission deadline.
>>>
>>> I request the mentors and everyone in the community who has experience
>>> in RTEMS, to please go through my proposal for Coverage Analysis tool
>>> improvement project , if they have time , and suggest any kind of
>>> improvements and changes .
>>> here is the link to the proposal
>>> https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SC
>>> rLETlerxD6t0SOcQNLQ/edit?usp=sharing
>>> Thank you
>>>
>>> -- vijay
>>>
>>> On 22 March 2018 at 04:30, Joel Sherrill  wrote:
>>>
 Glad you have tests running. Hopefully as Cillian suggested, you can
 fix the
 remaining issues to see coverage.

 We certainly need to get this merged if Chris is OK with it and it
 doesn't
 break anything else.

 I am reviewing proposals now. Seems to be a queue. :)

 --joel

 On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> Sir ,
> I have done the changes in the proposal , based on the comments in the
> google doc , please review it and suggest any further changes if required
>
> Thank you ,
> -- vijay
>
> P.S : the previous version is in parentheses , I will remove them
> after you review the changes .
>
> On 18 March 2018 at 16:05, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> Thanks Cillian :)
>>
>> It's great to see it running ,  I'll do some background reading about
>> RSB, and RTEMS-Tools along with the covoar code . And also work on my
>> python skills.
>>
>> to try rtems-test on a bsp that runs gdb , I tried it on erc32 and
>> that also worked.
>>
>> I'm also waiting for Joel and other mentors' review on my draft
>> proposal, so that I can also work on it and make any changes if needed.
>>
>> Thanks .
>>
>> -- vijay
>>
>> On 18 March 2018 at 14:17, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 18 March 2018 at 06:47, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 It worked !

>>>
>>> That's great!  That's the good news then. I was using an old leon3
>>> build and maybe some older Qemu too and I think that's why I didn't see 
>>> any
>>> issues initially. I was hoping you could see the coverage running and 
>>> the
>>> reports generated from that but it looks like the full update to the
>>> current master will be necessary to have a look. So until the parsing 
>>> for
>>> the INI files is added to the coverage.py we won't see the coverage
>>> running. Unfortunately, I'm in the middle of exams until the following
>>> Monday so I won't be able to sink any more time into it until then. You 
>>> can
>>> still figure out the RSB problem you're having and do some background
>>> reading, brush up on your Python skills, have a read of the covoar code
>>>
>>> https://github.com/RTEMS/rtems-tools/blob/master/tester/covo
>>> ar/covoar.cc
>>>
>>> just skim through, read the comments, get a sense of the what it's
>>> doing and in what order.
>>>
>>>
 It's great to see it running ! I have attached the result .

 -- vijay

 On 18 March 2018 at 02:31, Cillian O'Donnell  wrote:

>
>
> On 17 March 2018 at 20:08, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> yes it prints hello world
>>
>
> Alright I've added an .ini for leon3-qemu to the current
> rtems-tools. Pull this branch
>
> https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>
> and try
>
> $HOME/development/rtems/test/rtems-tools/tester/rtems-test
> --rtems-tools=$HOME/development/rtems/5
> --log=coverage-analysis.log --rtems-bsp=leon3_qemu
> $HOME/development/rtems/leon3/sparc-rtems5/c/leon3/testsuite
> s/samples
>
>>
>> -- vijay
>>
>> On 18 March 2018 at 01:31, Cillian O'Donnell <

Re: Improve coverage analysis toolset

[Joel Sherrill]

I am out and not at a computer. Someone can double check me but I believe
you can replace the PDF you upload.

Unless someone answers soon, just upload it.

--joel

On Mar 25, 2018 2:37 PM, "Vijay Kumar Banerjee" 
wrote:

> It's the last day before the deadline!
> Please provide a final review of the proposal before submitting.
>
> Thanks
>
> -- vijay
>
> On 24 March 2018 at 21:37, Vijay Kumar Banerjee 
> wrote:
>
>> hello mentors and other developers of the community , there are only
>> three days remaining to the GSoC proposal submission deadline.
>>
>> I request the mentors and everyone in the community who has experience in
>> RTEMS, to please go through my proposal for Coverage Analysis tool
>> improvement project , if they have time , and suggest any kind of
>> improvements and changes .
>> here is the link to the proposal
>> https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SC
>> rLETlerxD6t0SOcQNLQ/edit?usp=sharing
>> Thank you
>>
>> -- vijay
>>
>> On 22 March 2018 at 04:30, Joel Sherrill  wrote:
>>
>>> Glad you have tests running. Hopefully as Cillian suggested, you can fix
>>> the
>>> remaining issues to see coverage.
>>>
>>> We certainly need to get this merged if Chris is OK with it and it
>>> doesn't
>>> break anything else.
>>>
>>> I am reviewing proposals now. Seems to be a queue. :)
>>>
>>> --joel
>>>
>>> On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Sir ,
 I have done the changes in the proposal , based on the comments in the
 google doc , please review it and suggest any further changes if required

 Thank you ,
 -- vijay

 P.S : the previous version is in parentheses , I will remove them after
 you review the changes .

 On 18 March 2018 at 16:05, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> Thanks Cillian :)
>
> It's great to see it running ,  I'll do some background reading about
> RSB, and RTEMS-Tools along with the covoar code . And also work on my
> python skills.
>
> to try rtems-test on a bsp that runs gdb , I tried it on erc32 and
> that also worked.
>
> I'm also waiting for Joel and other mentors' review on my draft
> proposal, so that I can also work on it and make any changes if needed.
>
> Thanks .
>
> -- vijay
>
> On 18 March 2018 at 14:17, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 18 March 2018 at 06:47, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> It worked !
>>>
>>
>> That's great!  That's the good news then. I was using an old leon3
>> build and maybe some older Qemu too and I think that's why I didn't see 
>> any
>> issues initially. I was hoping you could see the coverage running and the
>> reports generated from that but it looks like the full update to the
>> current master will be necessary to have a look. So until the parsing for
>> the INI files is added to the coverage.py we won't see the coverage
>> running. Unfortunately, I'm in the middle of exams until the following
>> Monday so I won't be able to sink any more time into it until then. You 
>> can
>> still figure out the RSB problem you're having and do some background
>> reading, brush up on your Python skills, have a read of the covoar code
>>
>> https://github.com/RTEMS/rtems-tools/blob/master/tester/covo
>> ar/covoar.cc
>>
>> just skim through, read the comments, get a sense of the what it's
>> doing and in what order.
>>
>>
>>> It's great to see it running ! I have attached the result .
>>>
>>> -- vijay
>>>
>>> On 18 March 2018 at 02:31, Cillian O'Donnell 
>>> wrote:
>>>


 On 17 March 2018 at 20:08, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> yes it prints hello world
>

 Alright I've added an .ini for leon3-qemu to the current
 rtems-tools. Pull this branch

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

 and try

 $HOME/development/rtems/test/rtems-tools/tester/rtems-test
 --rtems-tools=$HOME/development/rtems/5
 --log=coverage-analysis.log --rtems-bsp=leon3_qemu
 $HOME/development/rtems/leon3/sparc-rtems5/c/leon3/testsuite
 s/samples

>
> -- vijay
>
> On 18 March 2018 at 01:31, Cillian O'Donnell <
> cpodonne...@gmail.com> wrote:
>
>> If you run just one test by itself without rtems-test
>>
>> qemu-system-sparc -no-reboot -monitor null -serial stdio
>> -nographic -M leon3_generic -kernel $HOME/development/rtems/leon3/
>> 

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

It's the last day before the deadline!
Please provide a final review of the proposal before submitting.

Thanks

-- vijay

On 24 March 2018 at 21:37, Vijay Kumar Banerjee 
wrote:

> hello mentors and other developers of the community , there are only three
> days remaining to the GSoC proposal submission deadline.
>
> I request the mentors and everyone in the community who has experience in
> RTEMS, to please go through my proposal for Coverage Analysis tool
> improvement project , if they have time , and suggest any kind of
> improvements and changes .
> here is the link to the proposal
> https://docs.google.com/document/d/1UjCWE1ojrpDQLQ2fQqxHU0SCrLETl
> erxD6t0SOcQNLQ/edit?usp=sharing
> Thank you
>
> -- vijay
>
> On 22 March 2018 at 04:30, Joel Sherrill  wrote:
>
>> Glad you have tests running. Hopefully as Cillian suggested, you can fix
>> the
>> remaining issues to see coverage.
>>
>> We certainly need to get this merged if Chris is OK with it and it doesn't
>> break anything else.
>>
>> I am reviewing proposals now. Seems to be a queue. :)
>>
>> --joel
>>
>> On Wed, Mar 21, 2018 at 4:42 AM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> Sir ,
>>> I have done the changes in the proposal , based on the comments in the
>>> google doc , please review it and suggest any further changes if required
>>>
>>> Thank you ,
>>> -- vijay
>>>
>>> P.S : the previous version is in parentheses , I will remove them after
>>> you review the changes .
>>>
>>> On 18 March 2018 at 16:05, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 Thanks Cillian :)

 It's great to see it running ,  I'll do some background reading about
 RSB, and RTEMS-Tools along with the covoar code . And also work on my
 python skills.

 to try rtems-test on a bsp that runs gdb , I tried it on erc32 and that
 also worked.

 I'm also waiting for Joel and other mentors' review on my draft
 proposal, so that I can also work on it and make any changes if needed.

 Thanks .

 -- vijay

 On 18 March 2018 at 14:17, Cillian O'Donnell 
 wrote:

>
>
> On 18 March 2018 at 06:47, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> It worked !
>>
>
> That's great!  That's the good news then. I was using an old leon3
> build and maybe some older Qemu too and I think that's why I didn't see 
> any
> issues initially. I was hoping you could see the coverage running and the
> reports generated from that but it looks like the full update to the
> current master will be necessary to have a look. So until the parsing for
> the INI files is added to the coverage.py we won't see the coverage
> running. Unfortunately, I'm in the middle of exams until the following
> Monday so I won't be able to sink any more time into it until then. You 
> can
> still figure out the RSB problem you're having and do some background
> reading, brush up on your Python skills, have a read of the covoar code
>
> https://github.com/RTEMS/rtems-tools/blob/master/tester/covo
> ar/covoar.cc
>
> just skim through, read the comments, get a sense of the what it's
> doing and in what order.
>
>
>> It's great to see it running ! I have attached the result .
>>
>> -- vijay
>>
>> On 18 March 2018 at 02:31, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 17 March 2018 at 20:08, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 yes it prints hello world

>>>
>>> Alright I've added an .ini for leon3-qemu to the current
>>> rtems-tools. Pull this branch
>>>
>>> https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>>>
>>> and try
>>>
>>> $HOME/development/rtems/test/rtems-tools/tester/rtems-test
>>> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
>>> --rtems-bsp=leon3_qemu $HOME/development/rtems/leon3/
>>> sparc-rtems5/c/leon3/testsuites/samples
>>>

 -- vijay

 On 18 March 2018 at 01:31, Cillian O'Donnell  wrote:

> If you run just one test by itself without rtems-test
>
> qemu-system-sparc -no-reboot -monitor null -serial stdio
> -nographic -M leon3_generic -kernel $HOME/development/rtems/leon3/
> sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>
> Does the hello world print out?
>
> On 17 March 2018 at 14:46, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> I built it manually
>>
>> the environment variable PATH looks like this
>> /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
>> 

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

Sir ,
I have done the changes in the proposal , based on the comments in the
google doc , please review it and suggest any further changes if required

Thank you ,
-- vijay

P.S : the previous version is in parentheses , I will remove them after you
review the changes .

On 18 March 2018 at 16:05, Vijay Kumar Banerjee 
wrote:

> Thanks Cillian :)
>
> It's great to see it running ,  I'll do some background reading about RSB,
> and RTEMS-Tools along with the covoar code . And also work on my python
> skills.
>
> to try rtems-test on a bsp that runs gdb , I tried it on erc32 and that
> also worked.
>
> I'm also waiting for Joel and other mentors' review on my draft proposal,
> so that I can also work on it and make any changes if needed.
>
> Thanks .
>
> -- vijay
>
> On 18 March 2018 at 14:17, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 18 March 2018 at 06:47, Vijay Kumar Banerjee > > wrote:
>>
>>> It worked !
>>>
>>
>> That's great!  That's the good news then. I was using an old leon3 build
>> and maybe some older Qemu too and I think that's why I didn't see any
>> issues initially. I was hoping you could see the coverage running and the
>> reports generated from that but it looks like the full update to the
>> current master will be necessary to have a look. So until the parsing for
>> the INI files is added to the coverage.py we won't see the coverage
>> running. Unfortunately, I'm in the middle of exams until the following
>> Monday so I won't be able to sink any more time into it until then. You can
>> still figure out the RSB problem you're having and do some background
>> reading, brush up on your Python skills, have a read of the covoar code
>>
>> https://github.com/RTEMS/rtems-tools/blob/master/tester/covoar/covoar.cc
>>
>> just skim through, read the comments, get a sense of the what it's doing
>> and in what order.
>>
>>
>>> It's great to see it running ! I have attached the result .
>>>
>>> -- vijay
>>>
>>> On 18 March 2018 at 02:31, Cillian O'Donnell 
>>> wrote:
>>>


 On 17 March 2018 at 20:08, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> yes it prints hello world
>

 Alright I've added an .ini for leon3-qemu to the current rtems-tools.
 Pull this branch

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

 and try

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

>
> -- vijay
>
> On 18 March 2018 at 01:31, Cillian O'Donnell 
> wrote:
>
>> If you run just one test by itself without rtems-test
>>
>> qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic
>> -M leon3_generic -kernel $HOME/development/rtems/leon3/
>> sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>>
>> Does the hello world print out?
>>
>> On 17 March 2018 at 14:46, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> I built it manually
>>>
>>> the environment variable PATH looks like this
>>> /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
>>> ms/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/
>>> home/lunatic/.local/bin:/home/lunatic/bin
>>>
>>> I tried to run rtems-test again without --coverage , it gives the
>>> same result
>>> I have attached the log.
>>>
>>> -- vijay
>>>
>>> On 17 March 2018 at 00:55, Cillian O'Donnell 
>>> wrote:
>>>
 Yes this is something more than my build, I'll need someone a bit
 more expert in the RSB to step in there. In the meantime, lets just 
 build
 couverture-qemu manually so we can see is everything else working.

 git clone https://github.com/AdaCore/qemu

 cd qemu

 ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
 --disable-docs --disable-virtfs --disable-werror

 make

 make install

 then add the prefix to $PATH in .bashrc as well like before.

 export PATH=$HOME/qemu/install/bin:$PATH

 Then run rtem-test and see what happens


 On 16 March 2018 at 19:13, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> the same error comes when I try to build qemu from the
> RTEMS/rtems-source-builder as well
>
> is the issue coming from my system ? I'm using fedora 27 64bit
>
> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
> vijaykumar9...@gmail.com> wrote:
>
>> yes , the same thing 

Re: Improve coverage analysis toolset

[Cillian O'Donnell]

On 18 March 2018 at 06:51, Vijay Kumar Banerjee 
wrote:

> I guess I couldn't understand properly what you're suggesting ,
> on the basis of what I understood ,
> I have set the PATH like this
> /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/luna
> tic/.local/bin:/home/lunatic/bin
>

I think this is about Joel's comment, it should go in the other thread for
that issue. That is what he meant so it must be something else then.

>
> I'm still getting the same error
>
>
> -- vijay
>
> On 17 March 2018 at 20:24, Joel Sherrill  wrote:
>
>> My guess on the build error is that the automake version used by RTEMS is
>> very old and may not produce output for --help that help2man can parse.
>>
>> Try building qemu from the RSB without the RTEMS tools in your PATH.
>>
>> If Couverture has been updated to a recent enough version of the upstream
>> qemu, then it is likely to fail the same way.
>>
>> --joel
>>
>> On Mar 17, 2018 9:46 AM, "Vijay Kumar Banerjee" 
>> wrote:
>>
>>> I built it manually
>>>
>>> the environment variable PATH looks like this
>>> /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
>>> ms/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/
>>> home/lunatic/.local/bin:/home/lunatic/bin
>>>
>>> I tried to run rtems-test again without --coverage , it gives the same
>>> result
>>> I have attached the log.
>>>
>>> -- vijay
>>>
>>> On 17 March 2018 at 00:55, Cillian O'Donnell 
>>> wrote:
>>>
 Yes this is something more than my build, I'll need someone a bit more
 expert in the RSB to step in there. In the meantime, lets just build
 couverture-qemu manually so we can see is everything else working.

 git clone https://github.com/AdaCore/qemu

 cd qemu

 ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
 --disable-docs --disable-virtfs --disable-werror

 make

 make install

 then add the prefix to $PATH in .bashrc as well like before.

 export PATH=$HOME/qemu/install/bin:$PATH

 Then run rtem-test and see what happens


 On 16 March 2018 at 19:13, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> the same error comes when I try to build qemu from the
> RTEMS/rtems-source-builder as well
>
> is the issue coming from my system ? I'm using fedora 27 64bit
>
> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
> vijaykumar9...@gmail.com> wrote:
>
>> yes , the same thing happens
>>
>> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
>> wrote:
>>
>>> If you build regular qemu with the RSB, does the same thing happen?
>>>
>>> Try
>>>
>>> ../source-builder/sb-set-builder --log=qemu_log.txt
>>> --prefix=$HOME/development/5 devel/qemu
>>>
>>>
>>> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 still the same error

 -- vijay

 On 16 March 2018 at 21:39, Cillian O'Donnell  wrote:

> Just checked and the build was failing because one of the patches
> needed its hash to be updated to sha256. Just pushed that change. The 
> build
> finishes successfully on my end. Pull that change into 
> couverture-build
> branch and try it again. I'm not seeing any automake stuff here, so 
> just
> check that and let me know.
>
> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> building couverture-qemu from rtems-source-builder (
>> https://github.com/cillianodonnell/rtems-source-builder/tr
>> ee/couverture-build )
>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>>
>> I have attached the error report .
>>
>> -- vijay
>>
>> On 15 March 2018 at 19:17, Cillian O'Donnell <
>> cpodonne...@gmail.com> wrote:
>>
>>>
>>>
>>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 It runs with a bunch of errors . I have attached the log file

>>>
>>> Ok, I'm guessing you didn't set up Couverture-Qemu (special
>>> version of qemu designed for generating extra trace data for 
>>> coverage
>>> analysis). That's what those errors are about. I have an RSB build 
>>> for that.
>>>
>>> https://github.com/cillianodonnell/rtems-source-builder/tree
>>> /couverture-build
>>>
>>> and the instructions for building it are
>>>
>>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
>>> gCouverture-QemuwiththeRSB

Re: Improve coverage analysis toolset

[Cillian O'Donnell]

On 18 March 2018 at 06:47, Vijay Kumar Banerjee 
wrote:

> It worked !
>

That's great!  That's the good news then. I was using an old leon3 build
and maybe some older Qemu too and I think that's why I didn't see any
issues initially. I was hoping you could see the coverage running and the
reports generated from that but it looks like the full update to the
current master will be necessary to have a look. So until the parsing for
the INI files is added to the coverage.py we won't see the coverage
running. Unfortunately, I'm in the middle of exams until the following
Monday so I won't be able to sink any more time into it until then. You can
still figure out the RSB problem you're having and do some background
reading, brush up on your Python skills, have a read of the covoar code

https://github.com/RTEMS/rtems-tools/blob/master/tester/covoar/covoar.cc

just skim through, read the comments, get a sense of the what it's doing
and in what order.


> It's great to see it running ! I have attached the result .
>
> -- vijay
>
> On 18 March 2018 at 02:31, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 17 March 2018 at 20:08, Vijay Kumar Banerjee > > wrote:
>>
>>> yes it prints hello world
>>>
>>
>> Alright I've added an .ini for leon3-qemu to the current rtems-tools.
>> Pull this branch
>>
>> https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>>
>> and try
>>
>> $HOME/development/rtems/test/rtems-tools/tester/rtems-test
>> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
>> --rtems-bsp=leon3_qemu $HOME/development/rtems/leon3/
>> sparc-rtems5/c/leon3/testsuites/samples
>>
>>>
>>> -- vijay
>>>
>>> On 18 March 2018 at 01:31, Cillian O'Donnell 
>>> wrote:
>>>
 If you run just one test by itself without rtems-test

 qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M
 leon3_generic -kernel $HOME/development/rtems/leon3/
 sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe

 Does the hello world print out?

 On 17 March 2018 at 14:46, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> I built it manually
>
> the environment variable PATH looks like this
> /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
> ms/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/
> home/lunatic/.local/bin:/home/lunatic/bin
>
> I tried to run rtems-test again without --coverage , it gives the same
> result
> I have attached the log.
>
> -- vijay
>
> On 17 March 2018 at 00:55, Cillian O'Donnell 
> wrote:
>
>> Yes this is something more than my build, I'll need someone a bit
>> more expert in the RSB to step in there. In the meantime, lets just build
>> couverture-qemu manually so we can see is everything else working.
>>
>> git clone https://github.com/AdaCore/qemu
>>
>> cd qemu
>>
>> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
>> --disable-docs --disable-virtfs --disable-werror
>>
>> make
>>
>> make install
>>
>> then add the prefix to $PATH in .bashrc as well like before.
>>
>> export PATH=$HOME/qemu/install/bin:$PATH
>>
>> Then run rtem-test and see what happens
>>
>>
>> On 16 March 2018 at 19:13, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> the same error comes when I try to build qemu from the
>>> RTEMS/rtems-source-builder as well
>>>
>>> is the issue coming from my system ? I'm using fedora 27 64bit
>>>
>>> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 yes , the same thing happens

 On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" <
 cpodonne...@gmail.com> wrote:

> If you build regular qemu with the RSB, does the same thing happen?
>
> Try
>
> ../source-builder/sb-set-builder --log=qemu_log.txt
> --prefix=$HOME/development/5 devel/qemu
>
>
> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> still the same error
>>
>> -- vijay
>>
>> On 16 March 2018 at 21:39, Cillian O'Donnell <
>> cpodonne...@gmail.com> wrote:
>>
>>> Just checked and the build was failing because one of the
>>> patches needed its hash to be updated to sha256. Just pushed that 
>>> change.
>>> The build finishes successfully on my end. Pull that change into
>>> couverture-build branch and try it again. I'm not seeing any 
>>> automake stuff
>>> here, so just check that and let me know.
>>>
>>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
>>> 

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

I guess I couldn't understand properly what you're suggesting ,
on the basis of what I understood ,
I have set the PATH like this
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/
lunatic/.local/bin:/home/lunatic/bin

I'm still getting the same error


-- vijay

On 17 March 2018 at 20:24, Joel Sherrill  wrote:

> My guess on the build error is that the automake version used by RTEMS is
> very old and may not produce output for --help that help2man can parse.
>
> Try building qemu from the RSB without the RTEMS tools in your PATH.
>
> If Couverture has been updated to a recent enough version of the upstream
> qemu, then it is likely to fail the same way.
>
> --joel
>
> On Mar 17, 2018 9:46 AM, "Vijay Kumar Banerjee" 
> wrote:
>
>> I built it manually
>>
>> the environment variable PATH looks like this
>> /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
>> ms/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/
>> home/lunatic/.local/bin:/home/lunatic/bin
>>
>> I tried to run rtems-test again without --coverage , it gives the same
>> result
>> I have attached the log.
>>
>> -- vijay
>>
>> On 17 March 2018 at 00:55, Cillian O'Donnell 
>> wrote:
>>
>>> Yes this is something more than my build, I'll need someone a bit more
>>> expert in the RSB to step in there. In the meantime, lets just build
>>> couverture-qemu manually so we can see is everything else working.
>>>
>>> git clone https://github.com/AdaCore/qemu
>>>
>>> cd qemu
>>>
>>> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
>>> --disable-docs --disable-virtfs --disable-werror
>>>
>>> make
>>>
>>> make install
>>>
>>> then add the prefix to $PATH in .bashrc as well like before.
>>>
>>> export PATH=$HOME/qemu/install/bin:$PATH
>>>
>>> Then run rtem-test and see what happens
>>>
>>>
>>> On 16 March 2018 at 19:13, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 the same error comes when I try to build qemu from the
 RTEMS/rtems-source-builder as well

 is the issue coming from my system ? I'm using fedora 27 64bit

 On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
 vijaykumar9...@gmail.com> wrote:

> yes , the same thing happens
>
> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
> wrote:
>
>> If you build regular qemu with the RSB, does the same thing happen?
>>
>> Try
>>
>> ../source-builder/sb-set-builder --log=qemu_log.txt
>> --prefix=$HOME/development/5 devel/qemu
>>
>>
>> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> still the same error
>>>
>>> -- vijay
>>>
>>> On 16 March 2018 at 21:39, Cillian O'Donnell 
>>> wrote:
>>>
 Just checked and the build was failing because one of the patches
 needed its hash to be updated to sha256. Just pushed that change. The 
 build
 finishes successfully on my end. Pull that change into couverture-build
 branch and try it again. I'm not seeing any automake stuff here, so 
 just
 check that and let me know.

 On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> building couverture-qemu from rtems-source-builder (
> https://github.com/cillianodonnell/rtems-source-builder/tr
> ee/couverture-build )
> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>
> I have attached the error report .
>
> -- vijay
>
> On 15 March 2018 at 19:17, Cillian O'Donnell <
> cpodonne...@gmail.com> wrote:
>
>>
>>
>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> It runs with a bunch of errors . I have attached the log file
>>>
>>
>> Ok, I'm guessing you didn't set up Couverture-Qemu (special
>> version of qemu designed for generating extra trace data for coverage
>> analysis). That's what those errors are about. I have an RSB build 
>> for that.
>>
>> https://github.com/cillianodonnell/rtems-source-builder/tree
>> /couverture-build
>>
>> and the instructions for building it are
>>
>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
>> gCouverture-QemuwiththeRSB
>>
>> I know what the other problem is too. I have a specific
>> environment variable defined for the path, sorry I can't even 
>> remember
>> putting it there, I thought that was automatically generated 
>> (probably
>> should be, another thing to add to the list :)... ). So wherever you 
>> stuck
>> the export path for where the rsb 

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

It worked !
It's great to see it running ! I have attached the result .

-- vijay

On 18 March 2018 at 02:31, Cillian O'Donnell  wrote:

>
>
> On 17 March 2018 at 20:08, Vijay Kumar Banerjee 
> wrote:
>
>> yes it prints hello world
>>
>
> Alright I've added an .ini for leon3-qemu to the current rtems-tools. Pull
> this branch
>
> https://github.com/cillianodonnell/rtems-tools/tree/ini-update
>
> and try
>
> $HOME/development/rtems/test/rtems-tools/tester/rtems-test
> --rtems-tools=$HOME/development/rtems/5 --log=coverage-analysis.log
> --rtems-bsp=leon3_qemu $HOME/development/rtems/leon3/sparc-rtems5/c/leon3/
> testsuites/samples
>
>>
>> -- vijay
>>
>> On 18 March 2018 at 01:31, Cillian O'Donnell 
>> wrote:
>>
>>> If you run just one test by itself without rtems-test
>>>
>>> qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M
>>> leon3_generic -kernel $HOME/development/rtems/leon3/
>>> sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>>>
>>> Does the hello world print out?
>>>
>>> On 17 March 2018 at 14:46, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 I built it manually

 the environment variable PATH looks like this
 /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
 ms/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/
 home/lunatic/.local/bin:/home/lunatic/bin

 I tried to run rtems-test again without --coverage , it gives the same
 result
 I have attached the log.

 -- vijay

 On 17 March 2018 at 00:55, Cillian O'Donnell 
 wrote:

> Yes this is something more than my build, I'll need someone a bit more
> expert in the RSB to step in there. In the meantime, lets just build
> couverture-qemu manually so we can see is everything else working.
>
> git clone https://github.com/AdaCore/qemu
>
> cd qemu
>
> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
> --disable-docs --disable-virtfs --disable-werror
>
> make
>
> make install
>
> then add the prefix to $PATH in .bashrc as well like before.
>
> export PATH=$HOME/qemu/install/bin:$PATH
>
> Then run rtem-test and see what happens
>
>
> On 16 March 2018 at 19:13, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> the same error comes when I try to build qemu from the
>> RTEMS/rtems-source-builder as well
>>
>> is the issue coming from my system ? I'm using fedora 27 64bit
>>
>> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> yes , the same thing happens
>>>
>>> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" <
>>> cpodonne...@gmail.com> wrote:
>>>
 If you build regular qemu with the RSB, does the same thing happen?

 Try

 ../source-builder/sb-set-builder --log=qemu_log.txt
 --prefix=$HOME/development/5 devel/qemu


 On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> still the same error
>
> -- vijay
>
> On 16 March 2018 at 21:39, Cillian O'Donnell <
> cpodonne...@gmail.com> wrote:
>
>> Just checked and the build was failing because one of the patches
>> needed its hash to be updated to sha256. Just pushed that change. 
>> The build
>> finishes successfully on my end. Pull that change into 
>> couverture-build
>> branch and try it again. I'm not seeing any automake stuff here, so 
>> just
>> check that and let me know.
>>
>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> building couverture-qemu from rtems-source-builder (
>>> https://github.com/cillianodonnell/rtems-source-builder/tr
>>> ee/couverture-build )
>>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>>>
>>> I have attached the error report .
>>>
>>> -- vijay
>>>
>>> On 15 March 2018 at 19:17, Cillian O'Donnell <
>>> cpodonne...@gmail.com> wrote:
>>>


 On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> It runs with a bunch of errors . I have attached the log file
>

 Ok, I'm guessing you didn't set up Couverture-Qemu (special
 version of qemu designed for generating extra trace data for 
 coverage
 analysis). That's what those errors are about. I have an RSB build 
 for that.

 

Re: Improve coverage analysis toolset

[Cillian O'Donnell]

On 17 March 2018 at 20:08, Vijay Kumar Banerjee 
wrote:

> yes it prints hello world
>

Alright I've added an .ini for leon3-qemu to the current rtems-tools. Pull
this branch

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

and try

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

>
> -- vijay
>
> On 18 March 2018 at 01:31, Cillian O'Donnell 
> wrote:
>
>> If you run just one test by itself without rtems-test
>>
>> qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M
>> leon3_generic -kernel $HOME/development/rtems/leon3/
>> sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe
>>
>> Does the hello world print out?
>>
>> On 17 March 2018 at 14:46, Vijay Kumar Banerjee > > wrote:
>>
>>> I built it manually
>>>
>>> the environment variable PATH looks like this
>>> /home/lunatic/qemu/install/bin:/home/lunatic/development/rte
>>> ms/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/
>>> home/lunatic/.local/bin:/home/lunatic/bin
>>>
>>> I tried to run rtems-test again without --coverage , it gives the same
>>> result
>>> I have attached the log.
>>>
>>> -- vijay
>>>
>>> On 17 March 2018 at 00:55, Cillian O'Donnell 
>>> wrote:
>>>
 Yes this is something more than my build, I'll need someone a bit more
 expert in the RSB to step in there. In the meantime, lets just build
 couverture-qemu manually so we can see is everything else working.

 git clone https://github.com/AdaCore/qemu

 cd qemu

 ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
 --disable-docs --disable-virtfs --disable-werror

 make

 make install

 then add the prefix to $PATH in .bashrc as well like before.

 export PATH=$HOME/qemu/install/bin:$PATH

 Then run rtem-test and see what happens


 On 16 March 2018 at 19:13, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> the same error comes when I try to build qemu from the
> RTEMS/rtems-source-builder as well
>
> is the issue coming from my system ? I'm using fedora 27 64bit
>
> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
> vijaykumar9...@gmail.com> wrote:
>
>> yes , the same thing happens
>>
>> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
>> wrote:
>>
>>> If you build regular qemu with the RSB, does the same thing happen?
>>>
>>> Try
>>>
>>> ../source-builder/sb-set-builder --log=qemu_log.txt
>>> --prefix=$HOME/development/5 devel/qemu
>>>
>>>
>>> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 still the same error

 -- vijay

 On 16 March 2018 at 21:39, Cillian O'Donnell  wrote:

> Just checked and the build was failing because one of the patches
> needed its hash to be updated to sha256. Just pushed that change. The 
> build
> finishes successfully on my end. Pull that change into 
> couverture-build
> branch and try it again. I'm not seeing any automake stuff here, so 
> just
> check that and let me know.
>
> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> building couverture-qemu from rtems-source-builder (
>> https://github.com/cillianodonnell/rtems-source-builder/tr
>> ee/couverture-build )
>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>>
>> I have attached the error report .
>>
>> -- vijay
>>
>> On 15 March 2018 at 19:17, Cillian O'Donnell <
>> cpodonne...@gmail.com> wrote:
>>
>>>
>>>
>>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 It runs with a bunch of errors . I have attached the log file

>>>
>>> Ok, I'm guessing you didn't set up Couverture-Qemu (special
>>> version of qemu designed for generating extra trace data for 
>>> coverage
>>> analysis). That's what those errors are about. I have an RSB build 
>>> for that.
>>>
>>> https://github.com/cillianodonnell/rtems-source-builder/tree
>>> /couverture-build
>>>
>>> and the instructions for building it are
>>>
>>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
>>> gCouverture-QemuwiththeRSB
>>>
>>> I know what the other problem is too. I have a specific

Re: Improve coverage analysis toolset

[Cillian O'Donnell]

If you run just one test by itself without rtems-test

qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M
leon3_generic -kernel
$HOME/development/rtems/leon3/sparc-rtems5/c/leon3/testsuites/samples/hello/hello.exe

Does the hello world print out?

On 17 March 2018 at 14:46, Vijay Kumar Banerjee 
wrote:

> I built it manually
>
> the environment variable PATH looks like this
> /home/lunatic/qemu/install/bin:/home/lunatic/development/
> rtems/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/
> sbin:/home/lunatic/.local/bin:/home/lunatic/bin
>
> I tried to run rtems-test again without --coverage , it gives the same
> result
> I have attached the log.
>
> -- vijay
>
> On 17 March 2018 at 00:55, Cillian O'Donnell 
> wrote:
>
>> Yes this is something more than my build, I'll need someone a bit more
>> expert in the RSB to step in there. In the meantime, lets just build
>> couverture-qemu manually so we can see is everything else working.
>>
>> git clone https://github.com/AdaCore/qemu
>>
>> cd qemu
>>
>> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
>> --disable-docs --disable-virtfs --disable-werror
>>
>> make
>>
>> make install
>>
>> then add the prefix to $PATH in .bashrc as well like before.
>>
>> export PATH=$HOME/qemu/install/bin:$PATH
>>
>> Then run rtem-test and see what happens
>>
>>
>> On 16 March 2018 at 19:13, Vijay Kumar Banerjee > > wrote:
>>
>>> the same error comes when I try to build qemu from the
>>> RTEMS/rtems-source-builder as well
>>>
>>> is the issue coming from my system ? I'm using fedora 27 64bit
>>>
>>> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 yes , the same thing happens

 On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
 wrote:

> If you build regular qemu with the RSB, does the same thing happen?
>
> Try
>
> ../source-builder/sb-set-builder --log=qemu_log.txt
> --prefix=$HOME/development/5 devel/qemu
>
>
> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> still the same error
>>
>> -- vijay
>>
>> On 16 March 2018 at 21:39, Cillian O'Donnell 
>> wrote:
>>
>>> Just checked and the build was failing because one of the patches
>>> needed its hash to be updated to sha256. Just pushed that change. The 
>>> build
>>> finishes successfully on my end. Pull that change into couverture-build
>>> branch and try it again. I'm not seeing any automake stuff here, so just
>>> check that and let me know.
>>>
>>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 building couverture-qemu from rtems-source-builder (
 https://github.com/cillianodonnell/rtems-source-builder/tr
 ee/couverture-build )
 gives error building auromake-1.12.6-x86_64-linux-gnu-1 .

 I have attached the error report .

 -- vijay

 On 15 March 2018 at 19:17, Cillian O'Donnell  wrote:

>
>
> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> It runs with a bunch of errors . I have attached the log file
>>
>
> Ok, I'm guessing you didn't set up Couverture-Qemu (special
> version of qemu designed for generating extra trace data for coverage
> analysis). That's what those errors are about. I have an RSB build 
> for that.
>
> https://github.com/cillianodonnell/rtems-source-builder/tree
> /couverture-build
>
> and the instructions for building it are
>
> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
> gCouverture-QemuwiththeRSB
>
> I know what the other problem is too. I have a specific
> environment variable defined for the path, sorry I can't even remember
> putting it there, I thought that was automatically generated (probably
> should be, another thing to add to the list :)... ). So wherever you 
> stuck
> the export path for where the rsb built the tools, in .bashrc or 
> whatever
> you're using. Also put something like:
>
> export PATH=$HOME/development/rtems/5
> /bin:$PATH
> export PATH=$HOME/development/rtems/t
> est/rtems-tools/build/tester/covoar:$PATH
>
> or you could just copy covoar into the /bin directory with all the
> other rsb tools gcc and all that, it'll find it either way.
>
>
>
>>
>> -- vijay
>>
>> On 15 March 2018 at 16:58, Cillian O'Donnell <
>> 

Re: Improve coverage analysis toolset

[Joel Sherrill]

My guess on the build error is that the automake version used by RTEMS is
very old and may not produce output for --help that help2man can parse.

Try building qemu from the RSB without the RTEMS tools in your PATH.

If Couverture has been updated to a recent enough version of the upstream
qemu, then it is likely to fail the same way.

--joel

On Mar 17, 2018 9:46 AM, "Vijay Kumar Banerjee" 
wrote:

> I built it manually
>
> the environment variable PATH looks like this
> /home/lunatic/qemu/install/bin:/home/lunatic/development/
> rtems/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/
> sbin:/home/lunatic/.local/bin:/home/lunatic/bin
>
> I tried to run rtems-test again without --coverage , it gives the same
> result
> I have attached the log.
>
> -- vijay
>
> On 17 March 2018 at 00:55, Cillian O'Donnell 
> wrote:
>
>> Yes this is something more than my build, I'll need someone a bit more
>> expert in the RSB to step in there. In the meantime, lets just build
>> couverture-qemu manually so we can see is everything else working.
>>
>> git clone https://github.com/AdaCore/qemu
>>
>> cd qemu
>>
>> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
>> --disable-docs --disable-virtfs --disable-werror
>>
>> make
>>
>> make install
>>
>> then add the prefix to $PATH in .bashrc as well like before.
>>
>> export PATH=$HOME/qemu/install/bin:$PATH
>>
>> Then run rtem-test and see what happens
>>
>>
>> On 16 March 2018 at 19:13, Vijay Kumar Banerjee > > wrote:
>>
>>> the same error comes when I try to build qemu from the
>>> RTEMS/rtems-source-builder as well
>>>
>>> is the issue coming from my system ? I'm using fedora 27 64bit
>>>
>>> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 yes , the same thing happens

 On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
 wrote:

> If you build regular qemu with the RSB, does the same thing happen?
>
> Try
>
> ../source-builder/sb-set-builder --log=qemu_log.txt
> --prefix=$HOME/development/5 devel/qemu
>
>
> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> still the same error
>>
>> -- vijay
>>
>> On 16 March 2018 at 21:39, Cillian O'Donnell 
>> wrote:
>>
>>> Just checked and the build was failing because one of the patches
>>> needed its hash to be updated to sha256. Just pushed that change. The 
>>> build
>>> finishes successfully on my end. Pull that change into couverture-build
>>> branch and try it again. I'm not seeing any automake stuff here, so just
>>> check that and let me know.
>>>
>>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 building couverture-qemu from rtems-source-builder (
 https://github.com/cillianodonnell/rtems-source-builder/tr
 ee/couverture-build )
 gives error building auromake-1.12.6-x86_64-linux-gnu-1 .

 I have attached the error report .

 -- vijay

 On 15 March 2018 at 19:17, Cillian O'Donnell  wrote:

>
>
> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> It runs with a bunch of errors . I have attached the log file
>>
>
> Ok, I'm guessing you didn't set up Couverture-Qemu (special
> version of qemu designed for generating extra trace data for coverage
> analysis). That's what those errors are about. I have an RSB build 
> for that.
>
> https://github.com/cillianodonnell/rtems-source-builder/tree
> /couverture-build
>
> and the instructions for building it are
>
> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
> gCouverture-QemuwiththeRSB
>
> I know what the other problem is too. I have a specific
> environment variable defined for the path, sorry I can't even remember
> putting it there, I thought that was automatically generated (probably
> should be, another thing to add to the list :)... ). So wherever you 
> stuck
> the export path for where the rsb built the tools, in .bashrc or 
> whatever
> you're using. Also put something like:
>
> export PATH=$HOME/development/rtems/5
> /bin:$PATH
> export PATH=$HOME/development/rtems/t
> est/rtems-tools/build/tester/covoar:$PATH
>
> or you could just copy covoar into the /bin directory with all the
> other rsb tools gcc and all that, it'll find it either way.
>
>
>
>>
>> -- vijay
>>

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

I built it manually

the environment variable PATH looks like this
/home/lunatic/qemu/install/bin:/home/lunatic/development/rtems/5/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/home/lunatic/.local/bin:/home/lunatic/bin

I tried to run rtems-test again without --coverage , it gives the same
result
I have attached the log.

-- vijay

On 17 March 2018 at 00:55, Cillian O'Donnell  wrote:

> Yes this is something more than my build, I'll need someone a bit more
> expert in the RSB to step in there. In the meantime, lets just build
> couverture-qemu manually so we can see is everything else working.
>
> git clone https://github.com/AdaCore/qemu
>
> cd qemu
>
> ./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
> --disable-docs --disable-virtfs --disable-werror
>
> make
>
> make install
>
> then add the prefix to $PATH in .bashrc as well like before.
>
> export PATH=$HOME/qemu/install/bin:$PATH
>
> Then run rtem-test and see what happens
>
>
> On 16 March 2018 at 19:13, Vijay Kumar Banerjee 
> wrote:
>
>> the same error comes when I try to build qemu from the
>> RTEMS/rtems-source-builder as well
>>
>> is the issue coming from my system ? I'm using fedora 27 64bit
>>
>> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> yes , the same thing happens
>>>
>>> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
>>> wrote:
>>>
 If you build regular qemu with the RSB, does the same thing happen?

 Try

 ../source-builder/sb-set-builder --log=qemu_log.txt
 --prefix=$HOME/development/5 devel/qemu


 On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> still the same error
>
> -- vijay
>
> On 16 March 2018 at 21:39, Cillian O'Donnell 
> wrote:
>
>> Just checked and the build was failing because one of the patches
>> needed its hash to be updated to sha256. Just pushed that change. The 
>> build
>> finishes successfully on my end. Pull that change into couverture-build
>> branch and try it again. I'm not seeing any automake stuff here, so just
>> check that and let me know.
>>
>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> building couverture-qemu from rtems-source-builder (
>>> https://github.com/cillianodonnell/rtems-source-builder/tr
>>> ee/couverture-build )
>>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>>>
>>> I have attached the error report .
>>>
>>> -- vijay
>>>
>>> On 15 March 2018 at 19:17, Cillian O'Donnell 
>>> wrote:
>>>


 On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> It runs with a bunch of errors . I have attached the log file
>

 Ok, I'm guessing you didn't set up Couverture-Qemu (special version
 of qemu designed for generating extra trace data for coverage 
 analysis).
 That's what those errors are about. I have an RSB build for that.

 https://github.com/cillianodonnell/rtems-source-builder/tree
 /couverture-build

 and the instructions for building it are

 https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
 gCouverture-QemuwiththeRSB

 I know what the other problem is too. I have a specific environment
 variable defined for the path, sorry I can't even remember putting it
 there, I thought that was automatically generated (probably should be,
 another thing to add to the list :)... ). So wherever you stuck the 
 export
 path for where the rsb built the tools, in .bashrc or whatever you're
 using. Also put something like:

 export PATH=$HOME/development/rtems/5/bin:$PATH

 export 
 PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH


 or you could just copy covoar into the /bin directory with all the
 other rsb tools gcc and all that, it'll find it either way.



>
> -- vijay
>
> On 15 March 2018 at 16:58, Cillian O'Donnell <
> cpodonne...@gmail.com> wrote:
>
>> Looks good. If you run the samples without coverage is everything
>> ok?
>>
>> So removing --coverage and tacking on /samples
>>
>> $HOME/development/rtems-tools/tester/rtems-test
>> --rtems-bsp=leon3-qemu --log=log-leon3.log 
>> --rtems-tools=$HOME/development/rtems/5
>> --rtems-builddir=$HOME/development/rtems/kernel/leon3
>> sparc-rtems5/c/leon3/testsuites/samples
>>
>> Do the 

Re: Improve coverage analysis toolset

[Gedare Bloom]

Vijay,

On Fri, Mar 16, 2018 at 10:59 AM, Vijay Kumar Banerjee
 wrote:
> building couverture-qemu from rtems-source-builder (
> https://github.com/cillianodonnell/rtems-source-builder/tree/couverture-build
> )
> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>
> I have attached the error report .
>

Try to build just the autotools:
source-builder/sb-set-builder devel/autotools

Assuming that fails, report this as a problem in a separate email
thread to focus effort on fixing the right "bug".

> -- vijay
>
> On 15 March 2018 at 19:17, Cillian O'Donnell  wrote:
>>
>>
>>
>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee 
>> wrote:
>>>
>>> It runs with a bunch of errors . I have attached the log file
>>
>>
>> Ok, I'm guessing you didn't set up Couverture-Qemu (special version of
>> qemu designed for generating extra trace data for coverage analysis). That's
>> what those errors are about. I have an RSB build for that.
>>
>>
>> https://github.com/cillianodonnell/rtems-source-builder/tree/couverture-build
>>
>> and the instructions for building it are
>>
>>
>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#BuildingCouverture-QemuwiththeRSB
>>
>> I know what the other problem is too. I have a specific environment
>> variable defined for the path, sorry I can't even remember putting it there,
>> I thought that was automatically generated (probably should be, another
>> thing to add to the list :)... ). So wherever you stuck the export path for
>> where the rsb built the tools, in .bashrc or whatever you're using. Also put
>> something like:
>>
>> export PATH=$HOME/development/rtems/5/bin:$PATH
>> export
>> PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH
>>
>> or you could just copy covoar into the /bin directory with all the other
>> rsb tools gcc and all that, it'll find it either way.
>>
>>
>>>
>>>
>>> -- vijay
>>>
>>> On 15 March 2018 at 16:58, Cillian O'Donnell 
>>> wrote:

 Looks good. If you run the samples without coverage is everything ok?

 So removing --coverage and tacking on /samples

 $HOME/development/rtems-tools/tester/rtems-test --rtems-bsp=leon3-qemu
 --log=log-leon3.log --rtems-tools=$HOME/development/rtems/5
 --rtems-builddir=$HOME/development/rtems/kernel/leon3
 sparc-rtems5/c/leon3/testsuites/samples

 Do the tests run?

 On 15 March 2018 at 10:53, Vijay Kumar Banerjee
  wrote:
>
> I have attached the output of the ls of that directory
>
> -- vijay
>
> On 15 March 2018 at 15:52, Cillian O'Donnell 
> wrote:
>>
>>
>>
>> On 15 March 2018 at 03:58, Vijay Kumar Banerjee
>>  wrote:
>>>
>>>
>>> hello ,
>>>
>>> as told by Joel , I started this thread to further discuss the
>>> coverage analysis toolset .
>>>
>>> Current status is , I'm trying to builld and run rtems-test from the
>>> coverage-merge branch of the previous GSoC student Cillian .
>>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>>>
>>> I'm getting an error that says .
>>>  "Covoar not found !"
>>
>>
>> It's supposed to find it in rtems-tools/build/tester/covoar/ If it's
>> in there it should be fine. Can you show me the contents of that 
>> directory?
>>
>> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $
>> ls
>>
>>
>>>
>>> the Covoar appeared in rtems-tools/tester/covoar .
>>>
>>> --
>>>
>>> Vijay
>>>
>>> ___
>>> 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: Improve coverage analysis toolset

[Cillian O'Donnell]

Yes this is something more than my build, I'll need someone a bit more
expert in the RSB to step in there. In the meantime, lets just build
couverture-qemu manually so we can see is everything else working.

git clone https://github.com/AdaCore/qemu

cd qemu

./configure --target-list=sparc-softmmu --prefix=$HOME/qemu/install
--disable-docs --disable-virtfs --disable-werror

make

make install

then add the prefix to $PATH in .bashrc as well like before.

export PATH=$HOME/qemu/install/bin:$PATH

Then run rtem-test and see what happens


On 16 March 2018 at 19:13, Vijay Kumar Banerjee 
wrote:

> the same error comes when I try to build qemu from the
> RTEMS/rtems-source-builder as well
>
> is the issue coming from my system ? I'm using fedora 27 64bit
>
> On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" <
> vijaykumar9...@gmail.com> wrote:
>
>> yes , the same thing happens
>>
>> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
>> wrote:
>>
>>> If you build regular qemu with the RSB, does the same thing happen?
>>>
>>> Try
>>>
>>> ../source-builder/sb-set-builder --log=qemu_log.txt
>>> --prefix=$HOME/development/5 devel/qemu
>>>
>>>
>>> On 16 March 2018 at 16:48, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 still the same error

 -- vijay

 On 16 March 2018 at 21:39, Cillian O'Donnell 
 wrote:

> Just checked and the build was failing because one of the patches
> needed its hash to be updated to sha256. Just pushed that change. The 
> build
> finishes successfully on my end. Pull that change into couverture-build
> branch and try it again. I'm not seeing any automake stuff here, so just
> check that and let me know.
>
> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> building couverture-qemu from rtems-source-builder (
>> https://github.com/cillianodonnell/rtems-source-builder/tr
>> ee/couverture-build )
>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>>
>> I have attached the error report .
>>
>> -- vijay
>>
>> On 15 March 2018 at 19:17, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 It runs with a bunch of errors . I have attached the log file

>>>
>>> Ok, I'm guessing you didn't set up Couverture-Qemu (special version
>>> of qemu designed for generating extra trace data for coverage analysis).
>>> That's what those errors are about. I have an RSB build for that.
>>>
>>> https://github.com/cillianodonnell/rtems-source-builder/tree
>>> /couverture-build
>>>
>>> and the instructions for building it are
>>>
>>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
>>> gCouverture-QemuwiththeRSB
>>>
>>> I know what the other problem is too. I have a specific environment
>>> variable defined for the path, sorry I can't even remember putting it
>>> there, I thought that was automatically generated (probably should be,
>>> another thing to add to the list :)... ). So wherever you stuck the 
>>> export
>>> path for where the rsb built the tools, in .bashrc or whatever you're
>>> using. Also put something like:
>>>
>>> export PATH=$HOME/development/rtems/5/bin:$PATH
>>>
>>> export 
>>> PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH
>>>
>>>
>>> or you could just copy covoar into the /bin directory with all the
>>> other rsb tools gcc and all that, it'll find it either way.
>>>
>>>
>>>

 -- vijay

 On 15 March 2018 at 16:58, Cillian O'Donnell  wrote:

> Looks good. If you run the samples without coverage is everything
> ok?
>
> So removing --coverage and tacking on /samples
>
> $HOME/development/rtems-tools/tester/rtems-test
> --rtems-bsp=leon3-qemu --log=log-leon3.log 
> --rtems-tools=$HOME/development/rtems/5
> --rtems-builddir=$HOME/development/rtems/kernel/leon3
> sparc-rtems5/c/leon3/testsuites/samples
>
> Do the tests run?
>
> On 15 March 2018 at 10:53, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> I have attached the output of the ls of that directory
>>
>> -- vijay
>>
>> On 15 March 2018 at 15:52, Cillian O'Donnell <
>> cpodonne...@gmail.com> wrote:
>>
>>>
>>>
>>> On 15 March 2018 at 03:58, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>

 hello ,

 as told by Joel , I started 

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

the same error comes when I try to build qemu from the
RTEMS/rtems-source-builder as well

is the issue coming from my system ? I'm using fedora 27 64bit

On 17 Mar 2018 12:39 a.m., "Vijay Kumar Banerjee" 
wrote:

> yes , the same thing happens
>
> On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
> wrote:
>
>> If you build regular qemu with the RSB, does the same thing happen?
>>
>> Try
>>
>> ../source-builder/sb-set-builder --log=qemu_log.txt
>> --prefix=$HOME/development/5 devel/qemu
>>
>>
>> On 16 March 2018 at 16:48, Vijay Kumar Banerjee > > wrote:
>>
>>> still the same error
>>>
>>> -- vijay
>>>
>>> On 16 March 2018 at 21:39, Cillian O'Donnell 
>>> wrote:
>>>
 Just checked and the build was failing because one of the patches
 needed its hash to be updated to sha256. Just pushed that change. The build
 finishes successfully on my end. Pull that change into couverture-build
 branch and try it again. I'm not seeing any automake stuff here, so just
 check that and let me know.

 On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> building couverture-qemu from rtems-source-builder (
> https://github.com/cillianodonnell/rtems-source-builder/tr
> ee/couverture-build )
> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>
> I have attached the error report .
>
> -- vijay
>
> On 15 March 2018 at 19:17, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> It runs with a bunch of errors . I have attached the log file
>>>
>>
>> Ok, I'm guessing you didn't set up Couverture-Qemu (special version
>> of qemu designed for generating extra trace data for coverage analysis).
>> That's what those errors are about. I have an RSB build for that.
>>
>> https://github.com/cillianodonnell/rtems-source-builder/tree
>> /couverture-build
>>
>> and the instructions for building it are
>>
>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
>> gCouverture-QemuwiththeRSB
>>
>> I know what the other problem is too. I have a specific environment
>> variable defined for the path, sorry I can't even remember putting it
>> there, I thought that was automatically generated (probably should be,
>> another thing to add to the list :)... ). So wherever you stuck the 
>> export
>> path for where the rsb built the tools, in .bashrc or whatever you're
>> using. Also put something like:
>>
>> export PATH=$HOME/development/rtems/5/bin:$PATH
>>
>> export 
>> PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH
>>
>>
>> or you could just copy covoar into the /bin directory with all the
>> other rsb tools gcc and all that, it'll find it either way.
>>
>>
>>
>>>
>>> -- vijay
>>>
>>> On 15 March 2018 at 16:58, Cillian O'Donnell 
>>> wrote:
>>>
 Looks good. If you run the samples without coverage is everything
 ok?

 So removing --coverage and tacking on /samples

 $HOME/development/rtems-tools/tester/rtems-test
 --rtems-bsp=leon3-qemu --log=log-leon3.log 
 --rtems-tools=$HOME/development/rtems/5
 --rtems-builddir=$HOME/development/rtems/kernel/leon3
 sparc-rtems5/c/leon3/testsuites/samples

 Do the tests run?

 On 15 March 2018 at 10:53, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> I have attached the output of the ls of that directory
>
> -- vijay
>
> On 15 March 2018 at 15:52, Cillian O'Donnell <
> cpodonne...@gmail.com> wrote:
>
>>
>>
>> On 15 March 2018 at 03:58, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>> hello ,
>>>
>>> as told by Joel , I started this thread to further discuss the
>>> coverage analysis toolset .
>>>
>>> Current status is , I'm trying to builld and run rtems-test from
>>> the coverage-merge branch of the previous GSoC student Cillian .
>>> https://github.com/cillianodonnell/rtems-tools/tree/coverage
>>> -merge
>>>
>>> I'm getting an error that says .
>>>  "Covoar not found !"
>>>
>>
>> It's supposed to find it in rtems-tools/build/tester/covoar/ If
>> it's in there it should be fine. Can you show me the contents of that
>> directory?
>>
>> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar
>> $ ls
>>
>>
>>

Re: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

yes , the same thing happens

On 17 Mar 2018 12:13 a.m., "Cillian O'Donnell" 
wrote:

> If you build regular qemu with the RSB, does the same thing happen?
>
> Try
>
> ../source-builder/sb-set-builder --log=qemu_log.txt
> --prefix=$HOME/development/5 devel/qemu
>
>
> On 16 March 2018 at 16:48, Vijay Kumar Banerjee 
> wrote:
>
>> still the same error
>>
>> -- vijay
>>
>> On 16 March 2018 at 21:39, Cillian O'Donnell 
>> wrote:
>>
>>> Just checked and the build was failing because one of the patches needed
>>> its hash to be updated to sha256. Just pushed that change. The build
>>> finishes successfully on my end. Pull that change into couverture-build
>>> branch and try it again. I'm not seeing any automake stuff here, so just
>>> check that and let me know.
>>>
>>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 building couverture-qemu from rtems-source-builder (
 https://github.com/cillianodonnell/rtems-source-builder/tr
 ee/couverture-build )
 gives error building auromake-1.12.6-x86_64-linux-gnu-1 .

 I have attached the error report .

 -- vijay

 On 15 March 2018 at 19:17, Cillian O'Donnell 
 wrote:

>
>
> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> It runs with a bunch of errors . I have attached the log file
>>
>
> Ok, I'm guessing you didn't set up Couverture-Qemu (special version of
> qemu designed for generating extra trace data for coverage analysis).
> That's what those errors are about. I have an RSB build for that.
>
> https://github.com/cillianodonnell/rtems-source-builder/tree
> /couverture-build
>
> and the instructions for building it are
>
> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
> gCouverture-QemuwiththeRSB
>
> I know what the other problem is too. I have a specific environment
> variable defined for the path, sorry I can't even remember putting it
> there, I thought that was automatically generated (probably should be,
> another thing to add to the list :)... ). So wherever you stuck the export
> path for where the rsb built the tools, in .bashrc or whatever you're
> using. Also put something like:
>
> export PATH=$HOME/development/rtems/5/bin:$PATH
>
> export 
> PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH
>
>
> or you could just copy covoar into the /bin directory with all the
> other rsb tools gcc and all that, it'll find it either way.
>
>
>
>>
>> -- vijay
>>
>> On 15 March 2018 at 16:58, Cillian O'Donnell 
>> wrote:
>>
>>> Looks good. If you run the samples without coverage is everything ok?
>>>
>>> So removing --coverage and tacking on /samples
>>>
>>> $HOME/development/rtems-tools/tester/rtems-test
>>> --rtems-bsp=leon3-qemu --log=log-leon3.log 
>>> --rtems-tools=$HOME/development/rtems/5
>>> --rtems-builddir=$HOME/development/rtems/kernel/leon3
>>> sparc-rtems5/c/leon3/testsuites/samples
>>>
>>> Do the tests run?
>>>
>>> On 15 March 2018 at 10:53, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 I have attached the output of the ls of that directory

 -- vijay

 On 15 March 2018 at 15:52, Cillian O'Donnell  wrote:

>
>
> On 15 March 2018 at 03:58, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>> hello ,
>>
>> as told by Joel , I started this thread to further discuss the
>> coverage analysis toolset .
>>
>> Current status is , I'm trying to builld and run rtems-test from
>> the coverage-merge branch of the previous GSoC student Cillian .
>> https://github.com/cillianodonnell/rtems-tools/tree/coverage
>> -merge
>>
>> I'm getting an error that says .
>>  "Covoar not found !"
>>
>
> It's supposed to find it in rtems-tools/build/tester/covoar/ If
> it's in there it should be fine. Can you show me the contents of that
> directory?
>
> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar
> $ ls
>
>
>
>> the Covoar appeared in rtems-tools/tester/covoar .
>>
>> --
>>
>> Vijay
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>

>>>
>>
>

>>>
>>
>

Re: Improve coverage analysis toolset

[Cillian O'Donnell]

If you build regular qemu with the RSB, does the same thing happen?

Try

../source-builder/sb-set-builder --log=qemu_log.txt
--prefix=$HOME/development/5 devel/qemu


On 16 March 2018 at 16:48, Vijay Kumar Banerjee 
wrote:

> still the same error
>
> -- vijay
>
> On 16 March 2018 at 21:39, Cillian O'Donnell 
> wrote:
>
>> Just checked and the build was failing because one of the patches needed
>> its hash to be updated to sha256. Just pushed that change. The build
>> finishes successfully on my end. Pull that change into couverture-build
>> branch and try it again. I'm not seeing any automake stuff here, so just
>> check that and let me know.
>>
>> On 16 March 2018 at 14:59, Vijay Kumar Banerjee > > wrote:
>>
>>> building couverture-qemu from rtems-source-builder (
>>> https://github.com/cillianodonnell/rtems-source-builder/tr
>>> ee/couverture-build )
>>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>>>
>>> I have attached the error report .
>>>
>>> -- vijay
>>>
>>> On 15 March 2018 at 19:17, Cillian O'Donnell 
>>> wrote:
>>>


 On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> It runs with a bunch of errors . I have attached the log file
>

 Ok, I'm guessing you didn't set up Couverture-Qemu (special version of
 qemu designed for generating extra trace data for coverage analysis).
 That's what those errors are about. I have an RSB build for that.

 https://github.com/cillianodonnell/rtems-source-builder/tree
 /couverture-build

 and the instructions for building it are

 https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
 gCouverture-QemuwiththeRSB

 I know what the other problem is too. I have a specific environment
 variable defined for the path, sorry I can't even remember putting it
 there, I thought that was automatically generated (probably should be,
 another thing to add to the list :)... ). So wherever you stuck the export
 path for where the rsb built the tools, in .bashrc or whatever you're
 using. Also put something like:

 export PATH=$HOME/development/rtems/5/bin:$PATH

 export 
 PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH


 or you could just copy covoar into the /bin directory with all the
 other rsb tools gcc and all that, it'll find it either way.



>
> -- vijay
>
> On 15 March 2018 at 16:58, Cillian O'Donnell 
> wrote:
>
>> Looks good. If you run the samples without coverage is everything ok?
>>
>> So removing --coverage and tacking on /samples
>>
>> $HOME/development/rtems-tools/tester/rtems-test
>> --rtems-bsp=leon3-qemu --log=log-leon3.log 
>> --rtems-tools=$HOME/development/rtems/5
>> --rtems-builddir=$HOME/development/rtems/kernel/leon3
>> sparc-rtems5/c/leon3/testsuites/samples
>>
>> Do the tests run?
>>
>> On 15 March 2018 at 10:53, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> I have attached the output of the ls of that directory
>>>
>>> -- vijay
>>>
>>> On 15 March 2018 at 15:52, Cillian O'Donnell 
>>> wrote:
>>>


 On 15 March 2018 at 03:58, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

>
> hello ,
>
> as told by Joel , I started this thread to further discuss the
> coverage analysis toolset .
>
> Current status is , I'm trying to builld and run rtems-test from
> the coverage-merge branch of the previous GSoC student Cillian .
> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>
> I'm getting an error that says .
>  "Covoar not found !"
>

 It's supposed to find it in rtems-tools/build/tester/covoar/ If
 it's in there it should be fine. Can you show me the contents of that
 directory?

 cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar
 $ ls



> the Covoar appeared in rtems-tools/tester/covoar .
>
> --
>
> Vijay
>
> ___
> 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: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

still the same error

-- vijay

On 16 March 2018 at 21:39, Cillian O'Donnell  wrote:

> Just checked and the build was failing because one of the patches needed
> its hash to be updated to sha256. Just pushed that change. The build
> finishes successfully on my end. Pull that change into couverture-build
> branch and try it again. I'm not seeing any automake stuff here, so just
> check that and let me know.
>
> On 16 March 2018 at 14:59, Vijay Kumar Banerjee 
> wrote:
>
>> building couverture-qemu from rtems-source-builder (
>> https://github.com/cillianodonnell/rtems-source-builder/
>> tree/couverture-build )
>> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>>
>> I have attached the error report .
>>
>> -- vijay
>>
>> On 15 March 2018 at 19:17, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 It runs with a bunch of errors . I have attached the log file

>>>
>>> Ok, I'm guessing you didn't set up Couverture-Qemu (special version of
>>> qemu designed for generating extra trace data for coverage analysis).
>>> That's what those errors are about. I have an RSB build for that.
>>>
>>> https://github.com/cillianodonnell/rtems-source-builder/tree
>>> /couverture-build
>>>
>>> and the instructions for building it are
>>>
>>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
>>> gCouverture-QemuwiththeRSB
>>>
>>> I know what the other problem is too. I have a specific environment
>>> variable defined for the path, sorry I can't even remember putting it
>>> there, I thought that was automatically generated (probably should be,
>>> another thing to add to the list :)... ). So wherever you stuck the export
>>> path for where the rsb built the tools, in .bashrc or whatever you're
>>> using. Also put something like:
>>>
>>> export PATH=$HOME/development/rtems/5/bin:$PATH
>>>
>>> export 
>>> PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH
>>>
>>>
>>> or you could just copy covoar into the /bin directory with all the other
>>> rsb tools gcc and all that, it'll find it either way.
>>>
>>>
>>>

 -- vijay

 On 15 March 2018 at 16:58, Cillian O'Donnell 
 wrote:

> Looks good. If you run the samples without coverage is everything ok?
>
> So removing --coverage and tacking on /samples
>
> $HOME/development/rtems-tools/tester/rtems-test
> --rtems-bsp=leon3-qemu --log=log-leon3.log 
> --rtems-tools=$HOME/development/rtems/5
> --rtems-builddir=$HOME/development/rtems/kernel/leon3
> sparc-rtems5/c/leon3/testsuites/samples
>
> Do the tests run?
>
> On 15 March 2018 at 10:53, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> I have attached the output of the ls of that directory
>>
>> -- vijay
>>
>> On 15 March 2018 at 15:52, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 15 March 2018 at 03:58, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>

 hello ,

 as told by Joel , I started this thread to further discuss the
 coverage analysis toolset .

 Current status is , I'm trying to builld and run rtems-test from
 the coverage-merge branch of the previous GSoC student Cillian .
 https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge

 I'm getting an error that says .
  "Covoar not found !"

>>>
>>> It's supposed to find it in rtems-tools/build/tester/covoar/ If
>>> it's in there it should be fine. Can you show me the contents of that
>>> directory?
>>>
>>> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar
>>> $ ls
>>>
>>>
>>>
 the Covoar appeared in rtems-tools/tester/covoar .

 --

 Vijay

 ___
 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: Improve coverage analysis toolset

[Cillian O'Donnell]

Just checked and the build was failing because one of the patches needed
its hash to be updated to sha256. Just pushed that change. The build
finishes successfully on my end. Pull that change into couverture-build
branch and try it again. I'm not seeing any automake stuff here, so just
check that and let me know.

On 16 March 2018 at 14:59, Vijay Kumar Banerjee 
wrote:

> building couverture-qemu from rtems-source-builder ( https://github.com/
> cillianodonnell/rtems-source-builder/tree/couverture-build )
> gives error building auromake-1.12.6-x86_64-linux-gnu-1 .
>
> I have attached the error report .
>
> -- vijay
>
> On 15 March 2018 at 19:17, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 15 March 2018 at 12:26, Vijay Kumar Banerjee > > wrote:
>>
>>> It runs with a bunch of errors . I have attached the log file
>>>
>>
>> Ok, I'm guessing you didn't set up Couverture-Qemu (special version of
>> qemu designed for generating extra trace data for coverage analysis).
>> That's what those errors are about. I have an RSB build for that.
>>
>> https://github.com/cillianodonnell/rtems-source-builder/
>> tree/couverture-build
>>
>> and the instructions for building it are
>>
>> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#Buildin
>> gCouverture-QemuwiththeRSB
>>
>> I know what the other problem is too. I have a specific environment
>> variable defined for the path, sorry I can't even remember putting it
>> there, I thought that was automatically generated (probably should be,
>> another thing to add to the list :)... ). So wherever you stuck the export
>> path for where the rsb built the tools, in .bashrc or whatever you're
>> using. Also put something like:
>>
>> export PATH=$HOME/development/rtems/5/bin:$PATH
>>
>> export 
>> PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH
>>
>>
>> or you could just copy covoar into the /bin directory with all the other
>> rsb tools gcc and all that, it'll find it either way.
>>
>>
>>
>>>
>>> -- vijay
>>>
>>> On 15 March 2018 at 16:58, Cillian O'Donnell 
>>> wrote:
>>>
 Looks good. If you run the samples without coverage is everything ok?

 So removing --coverage and tacking on /samples

 $HOME/development/rtems-tools/tester/rtems-test --rtems-bsp=leon3-qemu
 --log=log-leon3.log --rtems-tools=$HOME/development/rtems/5
 --rtems-builddir=$HOME/development/rtems/kernel/leon3
 sparc-rtems5/c/leon3/testsuites/samples

 Do the tests run?

 On 15 March 2018 at 10:53, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> I have attached the output of the ls of that directory
>
> -- vijay
>
> On 15 March 2018 at 15:52, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 15 March 2018 at 03:58, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>> hello ,
>>>
>>> as told by Joel , I started this thread to further discuss the
>>> coverage analysis toolset .
>>>
>>> Current status is , I'm trying to builld and run rtems-test from the
>>> coverage-merge branch of the previous GSoC student Cillian .
>>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>>>
>>> I'm getting an error that says .
>>>  "Covoar not found !"
>>>
>>
>> It's supposed to find it in rtems-tools/build/tester/covoar/ If it's
>> in there it should be fine. Can you show me the contents of that 
>> directory?
>>
>> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $
>> ls
>>
>>
>>
>>> the Covoar appeared in rtems-tools/tester/covoar .
>>>
>>> --
>>>
>>> Vijay
>>>
>>> ___
>>> 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: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

building couverture-qemu from rtems-source-builder (
https://github.com/cillianodonnell/rtems-source-builder/tree/couverture-build
)
gives error building auromake-1.12.6-x86_64-linux-gnu-1 .

I have attached the error report .

-- vijay

On 15 March 2018 at 19:17, Cillian O'Donnell  wrote:

>
>
> On 15 March 2018 at 12:26, Vijay Kumar Banerjee 
> wrote:
>
>> It runs with a bunch of errors . I have attached the log file
>>
>
> Ok, I'm guessing you didn't set up Couverture-Qemu (special version of
> qemu designed for generating extra trace data for coverage analysis).
> That's what those errors are about. I have an RSB build for that.
>
> https://github.com/cillianodonnell/rtems-source-
> builder/tree/couverture-build
>
> and the instructions for building it are
>
> https://devel.rtems.org/wiki/GSoC/2017/coveragetools#BuildingCouverture-
> QemuwiththeRSB
>
> I know what the other problem is too. I have a specific environment
> variable defined for the path, sorry I can't even remember putting it
> there, I thought that was automatically generated (probably should be,
> another thing to add to the list :)... ). So wherever you stuck the export
> path for where the rsb built the tools, in .bashrc or whatever you're
> using. Also put something like:
>
> export PATH=$HOME/development/rtems/5/bin:$PATH
>
> export PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH
>
>
> or you could just copy covoar into the /bin directory with all the other
> rsb tools gcc and all that, it'll find it either way.
>
>
>
>>
>> -- vijay
>>
>> On 15 March 2018 at 16:58, Cillian O'Donnell 
>> wrote:
>>
>>> Looks good. If you run the samples without coverage is everything ok?
>>>
>>> So removing --coverage and tacking on /samples
>>>
>>> $HOME/development/rtems-tools/tester/rtems-test --rtems-bsp=leon3-qemu
>>> --log=log-leon3.log --rtems-tools=$HOME/development/rtems/5
>>> --rtems-builddir=$HOME/development/rtems/kernel/leon3
>>> sparc-rtems5/c/leon3/testsuites/samples
>>>
>>> Do the tests run?
>>>
>>> On 15 March 2018 at 10:53, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 I have attached the output of the ls of that directory

 -- vijay

 On 15 March 2018 at 15:52, Cillian O'Donnell 
 wrote:

>
>
> On 15 March 2018 at 03:58, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>>
>> hello ,
>>
>> as told by Joel , I started this thread to further discuss the
>> coverage analysis toolset .
>>
>> Current status is , I'm trying to builld and run rtems-test from the
>> coverage-merge branch of the previous GSoC student Cillian .
>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>>
>> I'm getting an error that says .
>>  "Covoar not found !"
>>
>
> It's supposed to find it in rtems-tools/build/tester/covoar/ If it's
> in there it should be fine. Can you show me the contents of that 
> directory?
>
> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $
> ls
>
>
>
>> the Covoar appeared in rtems-tools/tester/covoar .
>>
>> --
>>
>> Vijay
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>

>>>
>>
>
RTEMS Tools Project - Source Builder Error Report
 Build: error: building automake-1.12.6-x86_64-linux-gnu-1
 Command Line: ../source-builder/sb-set-builder --log=couverture_qemu_log.txt 
--prefix=/home/lunatic/development/rtems/5 devel/couverture-qemu
 Python: 2.7.14 (default, Jan 17 2018, 14:28:32) [GCC 7.2.1 20170915 (Red Hat 
7.2.1-2)]
 
https://github.com/cillianodonnell/rtems-source-builder.git/origin/1d11496627fb0302d9f6425a01b297499a53ee2a
 Linux lunatic 4.14.14-300.fc27.x86_64 #1 SMP Fri Jan 19 13:19:54 UTC 2018 
x86_64
Tail of the build log:
-r-xr-xr-x 1000/1000   443 2012-12-15 15:04 automake-1.12.6/t/tap-more-w.sh
-rwxr-xr-x 1000/1000  3150 2012-12-14 01:27 
automake-1.12.6/t/testsuite-summary-count.sh
-rwxr-xr-x 1000/1000  1509 2012-12-14 22:28 
automake-1.12.6/t/aclocal-path.sh
-rwxr-xr-x 1000/1000  1043 2012-12-14 22:28 automake-1.12.6/t/version6.sh
-rwxr-xr-x 1000/1000  2050 2012-12-14 22:28 
automake-1.12.6/t/distcheck-configure-flags-am.sh
-rwxr-xr-x 1000/1000  1577 2012-12-14 22:28 
automake-1.12.6/t/tests-environment-backcompat.sh
-rwxr-xr-x 1000/1000  2966 2012-12-14 22:28 automake-1.12.6/t/backcompat5.sh
-rwxr-xr-x 1000/1000   970 2012-12-14 22:28 automake-1.12.6/t/gcj2.sh
-rwxr-xr-x 1000/1000  1561 2012-12-14 22:28 automake-1.12.6/t/ccnoco3.sh
-r-xr-xr-x 1000/1000   218 2012-12-15 15:04 
automake-1.12.6/t/depcomp-lt-makedepend.tap
-rwxr-xr-x 1000/1000  1323 2012-12-14 22:28 automake-1.12.6/t/pr279.sh
-r-xr-xr-x 

Re: Improve coverage analysis toolset

[Cillian O'Donnell]

On 15 March 2018 at 12:26, Vijay Kumar Banerjee 
wrote:

> It runs with a bunch of errors . I have attached the log file
>

Ok, I'm guessing you didn't set up Couverture-Qemu (special version of qemu
designed for generating extra trace data for coverage analysis). That's
what those errors are about. I have an RSB build for that.

https://github.com/cillianodonnell/rtems-source-builder/tree/couverture-build

and the instructions for building it are

https://devel.rtems.org/wiki/GSoC/2017/coveragetools#BuildingCouverture-QemuwiththeRSB

I know what the other problem is too. I have a specific environment
variable defined for the path, sorry I can't even remember putting it
there, I thought that was automatically generated (probably should be,
another thing to add to the list :)... ). So wherever you stuck the export
path for where the rsb built the tools, in .bashrc or whatever you're
using. Also put something like:

export PATH=$HOME/development/rtems/5/bin:$PATH

export PATH=$HOME/development/rtems/test/rtems-tools/build/tester/covoar:$PATH


or you could just copy covoar into the /bin directory with all the other
rsb tools gcc and all that, it'll find it either way.



>
> -- vijay
>
> On 15 March 2018 at 16:58, Cillian O'Donnell 
> wrote:
>
>> Looks good. If you run the samples without coverage is everything ok?
>>
>> So removing --coverage and tacking on /samples
>>
>> $HOME/development/rtems-tools/tester/rtems-test --rtems-bsp=leon3-qemu
>> --log=log-leon3.log --rtems-tools=$HOME/development/rtems/5
>> --rtems-builddir=$HOME/development/rtems/kernel/leon3
>> sparc-rtems5/c/leon3/testsuites/samples
>>
>> Do the tests run?
>>
>> On 15 March 2018 at 10:53, Vijay Kumar Banerjee > > wrote:
>>
>>> I have attached the output of the ls of that directory
>>>
>>> -- vijay
>>>
>>> On 15 March 2018 at 15:52, Cillian O'Donnell 
>>> wrote:
>>>


 On 15 March 2018 at 03:58, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

>
> hello ,
>
> as told by Joel , I started this thread to further discuss the
> coverage analysis toolset .
>
> Current status is , I'm trying to builld and run rtems-test from the
> coverage-merge branch of the previous GSoC student Cillian .
> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>
> I'm getting an error that says .
>  "Covoar not found !"
>

 It's supposed to find it in rtems-tools/build/tester/covoar/ If it's
 in there it should be fine. Can you show me the contents of that directory?

 cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $ ls



> the Covoar appeared in rtems-tools/tester/covoar .
>
> --
>
> Vijay
>
> ___
> 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: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

It runs with a bunch of errors . I have attached the log file


-- vijay

On 15 March 2018 at 16:58, Cillian O'Donnell  wrote:

> Looks good. If you run the samples without coverage is everything ok?
>
> So removing --coverage and tacking on /samples
>
> $HOME/development/rtems-tools/tester/rtems-test --rtems-bsp=leon3-qemu
> --log=log-leon3.log --rtems-tools=$HOME/development/rtems/5
> --rtems-builddir=$HOME/development/rtems/kernel/leon3
> sparc-rtems5/c/leon3/testsuites/samples
>
> Do the tests run?
>
> On 15 March 2018 at 10:53, Vijay Kumar Banerjee 
> wrote:
>
>> I have attached the output of the ls of that directory
>>
>> -- vijay
>>
>> On 15 March 2018 at 15:52, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On 15 March 2018 at 03:58, Vijay Kumar Banerjee <
>>> vijaykumar9...@gmail.com> wrote:
>>>

 hello ,

 as told by Joel , I started this thread to further discuss the coverage
 analysis toolset .

 Current status is , I'm trying to builld and run rtems-test from the
 coverage-merge branch of the previous GSoC student Cillian .
 https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge

 I'm getting an error that says .
  "Covoar not found !"

>>>
>>> It's supposed to find it in rtems-tools/build/tester/covoar/ If it's in
>>> there it should be fine. Can you show me the contents of that directory?
>>>
>>> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $ ls
>>>
>>>
>>>
 the Covoar appeared in rtems-tools/tester/covoar .

 --

 Vijay

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

>>>
>>>
>>
>
RTEMS Testing - Tester, 4.12 (0d2263d34306)
 Command Line: /home/lunatic/development/rtems/test/rtems-tools/tester/rtems-test --rtems-bsp=leon3-qemu --log=log-leon3.log --rtems-tools=/home/lunatic/development/rtems/5 --rtems-builddir=/home/lunatic/development/rtems/kernel/leon3 sparc-rtems5/c/leon3/testsuites/samples
 Python: 2.7.14 (default, Jan 17 2018, 14:28:32) [GCC 7.2.1 20170915 (Red Hat 7.2.1-2)]
error: qemu.cfg:80: execute failed: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/cdtest/cdtest.exe: exit-code:2
error: qemu.cfg:80: execute failed: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture/capture.exe: exit-code:2
error: qemu.cfg:80: execute failed: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/fileio/fileio.exe: exit-code:2
error: qemu.cfg:80: execute failed: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe: exit-code:2
[ 1/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:1  | sparc/leon3: base_sp.exe
> run: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/base_sp/base_sp.exe
Result: invalidTime: 0:00:00.009039 base_sp.exe
[ 2/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:1  | sparc/leon3: capture.exe
> run: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/capture/capture.exe
Result: invalidTime: 0:00:00.019280 capture.exe
[ 3/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:0  | sparc/leon3: cdtest.exe
> run: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/cdtest/cdtest.exe
Result: invalidTime: 0:00:00.013551 cdtest.exe
[ 4/13] p:0  f:0  u:0  e:0  I:0  B:0  t:0  i:1  | sparc/leon3: fileio.exe
> run: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/fileio/fileio.exe
Result: invalidTime: 0:00:00.015444 fileio.exe
error: qemu.cfg:80: execute failed: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M leon3_generic -kernel /home/lunatic/development/rtems/kernel/leon3/sparc-rtems5/c/leon3/testsuites/samples/minimum/minimum.exe: exit-code:2
error: qemu.cfg:80: execute failed: qemu-system-sparc -no-reboot -monitor null -serial stdio -nographic -M leon3_generic -kernel 

Re: Improve coverage analysis toolset

[Cillian O'Donnell]

Looks good. If you run the samples without coverage is everything ok?

So removing --coverage and tacking on /samples

$HOME/development/rtems-tools/tester/rtems-test --rtems-bsp=leon3-qemu
--log=log-leon3.log --rtems-tools=$HOME/development/rtems/5
--rtems-builddir=$HOME/development/rtems/kernel/leon3 sparc-rtems5/c/leon3/
testsuites/samples

Do the tests run?

On 15 March 2018 at 10:53, Vijay Kumar Banerjee 
wrote:

> I have attached the output of the ls of that directory
>
> -- vijay
>
> On 15 March 2018 at 15:52, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On 15 March 2018 at 03:58, Vijay Kumar Banerjee > > wrote:
>>
>>>
>>> hello ,
>>>
>>> as told by Joel , I started this thread to further discuss the coverage
>>> analysis toolset .
>>>
>>> Current status is , I'm trying to builld and run rtems-test from the
>>> coverage-merge branch of the previous GSoC student Cillian .
>>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>>>
>>> I'm getting an error that says .
>>>  "Covoar not found !"
>>>
>>
>> It's supposed to find it in rtems-tools/build/tester/covoar/ If it's in
>> there it should be fine. Can you show me the contents of that directory?
>>
>> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $ ls
>>
>>
>>
>>> the Covoar appeared in rtems-tools/tester/covoar .
>>>
>>> --
>>>
>>> Vijay
>>>
>>> ___
>>> 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: Improve coverage analysis toolset

[Vijay Kumar Banerjee]

I have attached the output of the ls of that directory

-- vijay

On 15 March 2018 at 15:52, Cillian O'Donnell  wrote:

>
>
> On 15 March 2018 at 03:58, Vijay Kumar Banerjee 
> wrote:
>
>>
>> hello ,
>>
>> as told by Joel , I started this thread to further discuss the coverage
>> analysis toolset .
>>
>> Current status is , I'm trying to builld and run rtems-test from the
>> coverage-merge branch of the previous GSoC student Cillian .
>> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>>
>> I'm getting an error that says .
>>  "Covoar not found !"
>>
>
> It's supposed to find it in rtems-tools/build/tester/covoar/ If it's in
> there it should be fine. Can you show me the contents of that directory?
>
> cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $ ls
>
>
>
>> the Covoar appeared in rtems-tools/tester/covoar .
>>
>> --
>>
>> Vijay
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
>
app_common.cc.1.o
CoverageFactory.cc.1.o
CoverageMapBase.cc.1.o
CoverageMap.cc.1.o
CoverageRanges.cc.1.o
CoverageReaderBase.cc.1.o
CoverageReaderQEMU.cc.1.o
CoverageReaderRTEMS.cc.1.o
CoverageReaderSkyeye.cc.1.o
CoverageReaderTSIM.cc.1.o
CoverageWriterBase.cc.1.o
CoverageWriterRTEMS.cc.1.o
CoverageWriterSkyeye.cc.1.o
CoverageWriterTSIM.cc.1.o
covoar
covoar.cc.3.o
covoar-config.h
DesiredSymbols.cc.1.o
ExecutableInfo.cc.1.o
Explanations.cc.1.o
GcovData.cc.1.o
GcovFunctionData.cc.1.o
libccovoar.a
ObjdumpProcessor.cc.1.o
ReportsBase.cc.1.o
ReportsHtml.cc.1.o
ReportsText.cc.1.o
SymbolTable.cc.1.o
Target_arm.cc.1.o
TargetBase.cc.1.o
TargetFactory.cc.1.o
Target_i386.cc.1.o
Target_lm32.cc.1.o
Target_m68k.cc.1.o
Target_powerpc.cc.1.o
Target_sparc.cc.1.o
trace-converter
TraceConverter.cc.2.o
TraceList.cc.2.o
TraceReaderBase.cc.2.o
TraceReaderLogQEMU.cc.2.o
TraceWriterBase.cc.2.o
TraceWriterQEMU.cc.2.o
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Improve coverage analysis toolset

[Cillian O'Donnell]

On 15 March 2018 at 03:58, Vijay Kumar Banerjee 
wrote:

>
> hello ,
>
> as told by Joel , I started this thread to further discuss the coverage
> analysis toolset .
>
> Current status is , I'm trying to builld and run rtems-test from the
> coverage-merge branch of the previous GSoC student Cillian .
> https://github.com/cillianodonnell/rtems-tools/tree/coverage-merge
>
> I'm getting an error that says .
>  "Covoar not found !"
>

It's supposed to find it in rtems-tools/build/tester/covoar/ If it's in
there it should be fine. Can you show me the contents of that directory?

cpod@cpod ~/development/rtems/test/rtems-tools/build/tester/covoar $ ls



> the Covoar appeared in rtems-tools/tester/covoar .
>
> --
>
> Vijay
>
> ___
> 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