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

[Vijay Kumar Banerjee]

On 19 May 2018 at 04:26, Joel Sherrill  wrote:

> If you run nm on some of the executables, do you see the
> Is symbol? We need to.know its type.
>

I did this on the testsuites
find -iname '*.exe' -exec nm -A '{}' \; | grep '\'

which returned nothing .
am I using the right command ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Cillian O'Donnell]

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

> On 19 May 2018 at 03:29, Joel Sherrill  wrote:
>
>>
>>
>> On Fri, May 18, 2018 at 4:53 PM, Vijay Kumar Banerjee <
>> vijaykumar9...@gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, 19 May 2018, 03:06 Joel Sherrill,  wrote:
>>>


 On Fri, May 18, 2018 at 4:01 PM, Vijay Kumar Banerjee <
 vijaykumar9...@gmail.com> wrote:

> On 19 May 2018 at 02:29, Vijay Kumar Banerjee <
> vijaykumar9...@gmail.com> wrote:
>
>> On 19 May 2018 at 01:30, Cillian O'Donnell 
>> wrote:
>>
>>>
>>>
>>> On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>


 On 18 May 2018 at 19:09, Cillian O'Donnell 
 wrote:

>
>
> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>>
>> On 18 May 2018 at 12:30, Cillian O'Donnell > > wrote:
>>
>>
>>> Cool, you should run it for the full testsuite and take a look
>>> at that report (takes a while.. around 575 tests)
>>>

> When I try to run the full testsuites it gives the following
>> error . What could be causing this ?
>>
>
> If you run the full testsuite without the coverage options, does
> it still happen?
>
 No it seems to run fine without coverage.

>>>
>>> I vaguely remember seeing this before last year, I suspect that when
>>> things are cleared up in coverage.py it will dissappear. So don't worry
>>> about it for now, carry on with what you're doing. What branch are you
>>> working on at the moment?
>>>
>> The path to build directory from the executable path is working now !
>>
>> I'm working in this branch currently, I'll send a patch to all of it
>> together when it starts working.
>>
> I meant to say once the parsing of ini file starts working. the path
> to build directory is already working.
>
>> Please have a look and also suggest improvements where applicable .
>>
>> https://github.com/thelunatic/rtems-tools/tree/cov-tester-support.
>>
>> after this update, running it on full testsuits doesn't give that
>> error anymore but it has some other issue. The report doesn't shows data
>> only for samples even after running it for full testsuites
>>
>
 Do you have coverage output on all the tests?

>>> I have coverage output on tests under samples/ only .
>>> running it for the whole testsuits gives the same coverage output as
>>> with samples/
>>>

 Is the verbose output indicating that all the tests are being looped
 over?


>
>> and I'm getting this error :
>>
>> -
>> ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
>>
>

 Cillian must want to purge all memory of this type of message. :)

 This message indicates that a symbol of interest (e.g. a function) has
 one length
 in one executable file and a completely different one in a second.
 Cillian worked
 on one of these last summer which was because the method was padded with
 a different number of nops in each executable. That was supposed to be
 handled
 by covoar but he found a nasty bug.

 This particular one looks like it is for a GCC generated symbol which
 should
 have been ignored in the symbols of interest. My bet is that the way we
 formerly
 got the DesiredSymbols only got real methods. The new way must also be
 picking up some "local" symbols that gcc is generating.

 If we know either of those executables, we should be able to look at
 the
 symbol table with nm and figure out what Chris is pulling in that he
 shouldn't.

 Is this a fatal error or just a "give up" on this symbol in this
 executable?

>>> it doesn't break in the middle. Coverage does run but the report doesn't
>>> look proper
>>>
>>
>> This is an auto-generated symbol by gcc which will be in the middle of a
>> method.
>> DesiredSymbols should be ignoring symbols like this. I don't think seeing
>> them
>> will cause a horrible problem but it is quite likely that the method(s)
>> these are
>> seen in will have quite incorrect results.
>>
>> If running on samples looks OK, try running coverage from just tmtests and
>> see if that is better. You need to find a set small enough to trip the
>> problem
>> but easy to analyse.
>>
> Coverage from tmtests looks OK .
> psxtmtests , psxtests, libtests gives the same error and doesn't show
> proper coverage report.
>
> Also, I can see these INFO lines even with the ones that are showing
> proper coverage output
>
> --
> INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
> CSWTCH.1 because the sizes are diffe

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

[Vijay Kumar Banerjee]

On 19 May 2018 at 16:47, Cillian O'Donnell  wrote:

>
> God these messages again... at least I'm an expert in fixing these :)
> Vijay I'm only seeing the headings in the report on my end using your
> branch. How are you running it and from where? Is there any changes you
> haven't pushed?
>
I'm rurrning it from top of build tree, the latest change I pushed was
yesterday

and
I haven't made any changes after that. the report seems to be running here.

>
> Coverage run for score finished successfully.
>> ---
>>
>>
>>> --joel
>>>
>>>

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

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

[Cillian O'Donnell]

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

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

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

>
>> Coverage run for score finished successfully.
>>> ---
>>>
>>>
 --joel


>
>> --joel
>>
>>
>>>


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

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

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

[Vijay Kumar Banerjee]

On 19 May 2018 at 17:50, Vijay Kumar Banerjee 
wrote:

> On 19 May 2018 at 17:44, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 19 May 2018 at 16:47, Cillian O'Donnell 
>>> wrote:
>>>

 God these messages again... at least I'm an expert in fixing these :)
 Vijay I'm only seeing the headings in the report on my end using your
 branch. How are you running it and from where? Is there any changes you
 haven't pushed?

>>> I'm rurrning it from top of build tree, the latest change I pushed was
>>> yesterday
>>> 
>>>  and
>>> I haven't made any changes after that. the report seems to be running here.
>>>
>>
>> Strange.. if you clean everything away that covoar outputs and run it
>> again, can it still find the data?
>>
> please see the attached image.
> It seems to be working pretty fine.
>
> Can you please try cleaning out everything, fetching my cov-tester-support
branch, ./waf build install it and then try running tester form the top of
the build tree?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Vijay Kumar Banerjee]

On 19 May 2018 at 17:56, Vijay Kumar Banerjee 
wrote:

> On 19 May 2018 at 17:50, Vijay Kumar Banerjee 
> wrote:
>
>> On 19 May 2018 at 17:44, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>
 On 19 May 2018 at 16:47, Cillian O'Donnell 
 wrote:

>
> God these messages again... at least I'm an expert in fixing these :)
> Vijay I'm only seeing the headings in the report on my end using your
> branch. How are you running it and from where? Is there any changes you
> haven't pushed?
>
 I'm rurrning it from top of build tree, the latest change I pushed was
 yesterday
 
  and
 I haven't made any changes after that. the report seems to be running here.

>>>
>>> Strange.. if you clean everything away that covoar outputs and run it
>>> again, can it still find the data?
>>>
>> please see the attached image.
>> It seems to be working pretty fine.
>>
>> Can you please try cleaning out everything, fetching my
> cov-tester-support branch, ./waf build install it and then try running
> tester form the top of the build tree?
>
please run it for samples only, running it for whole testsuites is not
generating proper report currently.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Cillian O'Donnell]

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

> On 19 May 2018 at 17:56, Vijay Kumar Banerjee 
> wrote:
>
>> On 19 May 2018 at 17:50, Vijay Kumar Banerjee 
>> wrote:
>>
>>> On 19 May 2018 at 17:44, Cillian O'Donnell 
>>> wrote:
>>>


 On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
 vijaykumar9...@gmail.com> wrote:

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

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

>>> please see the attached image.
>>> It seems to be working pretty fine.
>>>
>>> Can you please try cleaning out everything, fetching my
>> cov-tester-support branch, ./waf build install it and then try running
>> tester form the top of the build tree?
>>
> please run it for samples only, running it for whole testsuites is not
> generating proper report currently.
>

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

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

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

[Vijay Kumar Banerjee]

On 19 May 2018 at 18:28, Cillian O'Donnell  wrote:

>
>
> On Sat, 19 May 2018, 13:28 Vijay Kumar Banerjee, 
> wrote:
>
>> On 19 May 2018 at 17:56, Vijay Kumar Banerjee 
>> wrote:
>>
>>> On 19 May 2018 at 17:50, Vijay Kumar Banerjee 
>>> wrote:
>>>
 On 19 May 2018 at 17:44, Cillian O'Donnell 
 wrote:

>
>
> On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
> vijaykumar9...@gmail.com> wrote:
>
>> On 19 May 2018 at 16:47, Cillian O'Donnell 
>> wrote:
>>
>>>
>>> God these messages again... at least I'm an expert in fixing these
>>> :) Vijay I'm only seeing the headings in the report on my end using your
>>> branch. How are you running it and from where? Is there any changes you
>>> haven't pushed?
>>>
>> I'm rurrning it from top of build tree, the latest change I pushed
>> was yesterday
>> 
>>  and
>> I haven't made any changes after that. the report seems to be running 
>> here.
>>
>
> Strange.. if you clean everything away that covoar outputs and run it
> again, can it still find the data?
>
 please see the attached image.
 It seems to be working pretty fine.

 Can you please try cleaning out everything, fetching my
>>> cov-tester-support branch, ./waf build install it and then try running
>>> tester form the top of the build tree?
>>>
>> please run it for samples only, running it for whole testsuites is not
>> generating proper report currently.
>>
>
> Yeah I'll give it another try when I get home. At the beach at the moment.
>
sure , enjoy !
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Gedare Bloom]

On Fri, May 18, 2018 at 5:53 PM, Joel Sherrill  wrote:
>
>
> On Fri, May 18, 2018 at 3:24 PM, Amaan Cheval 
> wrote:
>>
>> Hi everyone!
>>
>> I've written a quick blog post summarizing the options I've considered
>> to make the x86_64 port work with UEFI firmware - the primary winner
>> seems to be in my eyes to use "gnu-efi" and to add support for the
>> target "pei-x86-64" (aliased to "efi-app-x86_64") to
>> "x86_64-rtems5-objcopy" in binutils. I've submitted a patch for this
>> here[1].
>
>
> That patch is quite simple so shouldn't be a problem if this is the
> direction
> that gets consensus.
>>
>>
>> The blog post is here:
>> https://blog.whatthedude.com/post/uefi-app-options/
>>
>> I'd appreciate all feedback (and please do let me know if I haven't
>> provided enough context)!
>>
>> Specifically, some concerns I'd like to discuss are:
>>
>> - Does everyone agree with me on choosing gnu-efi + objcopy as our
>> method of choice?
>
>
> Does using gnu-efi add code that runs on the target? Can you point
> us to the files, if so.
>
> Can you tell which approach FreeBSD takes?
>
>>
>> - How do we integrate gnu-efi into our build process? A part of the
>> RSB, making sure the path to the libraries are in an exported
>> variable? Or perhaps a part of the RTEMS kernel itself if the licenses
>> are compatible (I don't see any on the project[2], only copyright
>> notices within the source files of the release versions).
>
>
> GNU-efi would be built like qemu or the device tree compiler would
> be my guess and x86_64-rtems toolset might add that to the standard
> set of tools. License on host tools being GPL isn't an issue.
>

It appears to be a standard 2-clause BSD released by Intel as
specified in the README file of gnu-efi.

>
>>
>> - Regardless of how we manage UEFI, do we require Multiboot support
>> too? Multiboot drops us in a 32-bit protected mode environment,
>> whereas 64-bit UEFI firmware will boot us into 64-bit long mode - this
>> would mean the kernel would need to support separate code-paths for
>> the 2 if we want to support both methods.
>
>
> That's a good question. For GSoC, I think UEFI is fine and perhaps a ticket
> under the general "modern PC support" ticket for multiboot support. Unless
> that eliminates a LOT of PCs.
>
> I don't want you to spend all summer getting an image to boot both
> ways. Personally, I want you to have a working BSP one way. :)
+1

>>
>>
>> [1] https://www.sourceware.org/ml/binutils/2018-05/msg00197.html
>> [2] https://sourceforge.net/projects/gnu-efi/
>
>
> --joel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Cillian O'Donnell]

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

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

> On 19 May 2018 at 18:28, Cillian O'Donnell  wrote:
>
>>
>>
>> On Sat, 19 May 2018, 13:28 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 19 May 2018 at 17:56, Vijay Kumar Banerjee 
>>> wrote:
>>>
 On 19 May 2018 at 17:50, Vijay Kumar Banerjee >>> > wrote:

> On 19 May 2018 at 17:44, Cillian O'Donnell 
> wrote:
>
>>
>>
>> On Sat, 19 May 2018, 12:28 Vijay Kumar Banerjee, <
>> vijaykumar9...@gmail.com> wrote:
>>
>>> On 19 May 2018 at 16:47, Cillian O'Donnell 
>>> wrote:
>>>

 God these messages again... at least I'm an expert in fixing these
 :) Vijay I'm only seeing the headings in the report on my end using 
 your
 branch. How are you running it and from where? Is there any changes you
 haven't pushed?

>>> I'm rurrning it from top of build tree, the latest change I pushed
>>> was yesterday
>>> 
>>>  and
>>> I haven't made any changes after that. the report seems to be running 
>>> here.
>>>
>>
>> Strange.. if you clean everything away that covoar outputs and run it
>> again, can it still find the data?
>>
> please see the attached image.
> It seems to be working pretty fine.
>
> Can you please try cleaning out everything, fetching my
 cov-tester-support branch, ./waf build install it and then try running
 tester form the top of the build tree?

>>> please run it for samples only, running it for whole testsuites is not
>>> generating proper report currently.
>>>
>>
>> Yeah I'll give it another try when I get home. At the beach at the moment.
>>
> sure , enjoy !
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Vijay Kumar Banerjee]

On Sun, 20 May 2018, 00:45 Cillian O'Donnell,  wrote:

> It works.. Sorry I was using the right covoar but the wrong rtems-test.
> Ahh its nice to see the data back in the reports again. Did you manage to
> track down 2 exes with the mismatch in symbol size?
>
Great! so next is the parsing of the symbol file.
I couldn't manage to track down the mismatch.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] c-user: changed RTEMS_STATUS_SUCCESSFUL to RTEMS_SUCCESSFUL

[Malte Münch]

---
 c-user/example_application.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/c-user/example_application.rst b/c-user/example_application.rst
index 194382e..8a030fd 100644
--- a/c-user/example_application.rst
+++ b/c-user/example_application.rst
@@ -35,13 +35,13 @@ Example Application
 name, 1, RTEMS_MINIMUM_STACK_SIZE,
 RTEMS_NO_PREEMPT, RTEMS_FLOATING_POINT, &tid
 );
-if ( status != RTEMS_STATUS_SUCCESSFUL ) {
+if ( status != RTEMS_SUCCESSFUL ) {
 printf( "rtems_task_create failed with status of %d.\n", status );
 exit( 1 );
 }
 
 status = rtems_task_start( tid, user_application, 0 );
-if ( status != RTEMS_STATUS_SUCCESSFUL ) {
+if ( status != RTEMS_SUCCESSFUL ) {
 printf( "rtems_task_start failed with status of %d.\n", status );
 exit( 1 );
 }
-- 
2.17.0

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

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

[Vijay Kumar Banerjee]

Hello,

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


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

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

[Cillian O'Donnell]

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

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

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

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

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

[Vijay Kumar Banerjee]

On Sun, 20 May 2018, 01:56 Cillian O'Donnell,  wrote:

>
>
> On Sat, 19 May 2018, 20:59 Vijay Kumar Banerjee, 
> wrote:
>
>> Hello,
>>
>> My end sem exams are starting next week from 22nd May and will go till
>> 31st May. During this period I will be less efficient.
>> I understand that the project is in a crucial state and 10 days of
>> inactivity is unacceptable so I will try my best to be as active as
>> possible during the gaps between the exam and keep working on the project
>> and the blog. I hope this is fine.
>>
>
> Yes that's fine, focus on your exams and do what you can. All the best, I
> hope they well for you Vijay. Good luck!
>
Thanks a lot ! :)

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

Re: [PATCH] c-user: changed RTEMS_STATUS_SUCCESSFUL to RTEMS_SUCCESSFUL

[Chris Johns]

On 20/5/18 7:31 am, Malte Münch wrote:
> ---
>  c-user/example_application.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Pushed. Thank you.

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

Re: LIST OF IO BENCHMARKS

[Udit agarwal]

Hi,

On Fri, May 18, 2018 at 11:19 PM, Gedare Bloom  wrote:

> Udit,
>
> Can you please compare pros/cons of FIO, IOZONE, and Bonnie++,
> probably in a blog post is a good idea.
>
Done, here

is the comparison.

>
> The GPLv2 is not a problem for test suites / benchmarks. It is only a
> problem for code that should get merged into the rtems.git.
>
> Gedare
>
> On Thu, May 17, 2018 at 5:20 AM, Udit agarwal 
> wrote:
> > Hi all,
> > As discussed in yesterday's IRC meeting, here is the list of different IO
> > benchmarks(which are supported by FreeBSD) in the decreasing order of
> their
> > popularity  :
> >
> > FIO - License type:  GPLv2 - Widely accepted for storage device
> benchmarking
> > IOZONE - License: Customized - Large number of features, Also used for
> > storage benchmarking
> > Bonnie++ - GPLv2 - Widely known filesystem benchmark, Not much used for
> > storage benchmarking.
> > IOMETER -  GPLv2 - Out of active development.
> > IORATE - Flexible - Out of active development
> >
> > I have performed SDIO-SDHCI performance analysis using IOZONE. Here are
> the
> > results. And i have documented the process on my blog.
> >
> > Regards,
> >
> > Udit Agarwal
> >
> >
> > ___
> > 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