Re: RTEMS Block Driver Execution Flow

[Chris Johns]

On 19/5/18 9:45 am, Joel Sherrill wrote:
> I am starting to write a block driver which doesn't have a media matching
> any of the existing ones. I was trying to get a feel for the flow of 
> operations
> and having trouble figuring it out. flashdisk looks to be a good guide except 
> it is using rtems_disk_create_phys() which #3358 marks as deprecated. 
> RAM disk and NV disk still use it also.
> 
> Where's the best discussion of this?
> 

Doxygen's ...

https://docs.rtems.org/doxygen/branches/master/group__rtems__libblock.html

?

>  Any other guidance?

As documented in the "Detailed Description" section

https://docs.rtems.org/doxygen/branches/master/group__rtems__bdbuf.html#details

the pool's memory can be used in pools of different sizes. This lets you have a
block size to read a file system's details from a superblock of some form and
from that the file system's block size which is then set.

The output workers can run in parallel if you have separate drivers configured.

I hope this helps.

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

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

[Joel Sherrill]

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

On Fri, May 18, 2018, 5:24 PM 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.
>

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

[Vijay Kumar Banerjee]

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  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 different
INFO: DesiredSymbols::mergeCoverageMap - Unable to merge coverage map for
_Thread_queue_Operations_default 

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

[Joel Sherrill]

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

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

>
> --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: [GSoC] Ways to make the x86_64 port work with UEFI

[Joel Sherrill]

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.



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

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

[Joel Sherrill]

Thanks. I will try to deal with this Monday.

My specs patches are not ready to push to gcc so I need to focus on
just the parts to make x86_64 right.

On Fri, May 18, 2018 at 3:41 PM, Amaan Cheval 
wrote:

> To be clear, I applied this patch (with my fixes) on the 7.3 release
> through the RSB to test, not on GCC's master branch.
>
> > to add i386/rtemself64.h
>
> What you sent in this email thread adds rtemself64.h already. Do you
> mean you'd like to split the commits up or something?
>
> The only changes I made on top of yours were:
>
> - Readd "rtems.h" to config.gcc
> - Fix comments
>
> I've attached the patch file I used within the RSB here (sorry if you
> meant a patch of _just_ the fixes I made on top of yours, this is just
> the cumulative diff I used to patch GCC 7.3 to test).
>
> Regards,
>
> On Fri, May 18, 2018 at 7:00 PM, Joel Sherrill  wrote:
> >
> >
> >
> > On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval 
> > wrote:
> >>
> >> I just compiled my local fixed copy (adding rtems.h back in) and
> >> there's good news! With the patch, the x86_64 compile stub works with
> >> a blank bsp_specs file!
> >
> >
> > Awesome!
> >
> > Can you send me your changes as a patch? I am thinking I need to make
> > sure we agree on what the gcc master for x86_64-rtems looks like.
> >
> > Apparently I owe committing a patch to add i386/rtemself64.h since it is
> > missing on the master. And the comment is wrong.  What else?
> >
> >> On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval 
> >> wrote:
> >> > Hey!
> >> >
> >> > Thanks so much for sharing this, it's quite useful to put your earlier
> >> > email[1] about minimzing the bsp_specs in context.
> >> >
> >> > From looking ahead a bit without testing (still compiling), the patch
> >> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it defines
> >> > __TMC_END__ which crtbegin.o has left undefined for eg.) and possibly
> >> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely
> >> > (see here[2]).
> >>
> >> Just noticed that ENDFILE_SPEC already includes crtend in i386elf.h,
> >> so there's no need for this change.
> >>
> >> >
> >> > I've also left some comments inline below.
> >> >
> >> > +1 on upstreaming this into GCC (making sure it also backports to 7.3
> >> > for simplicity, so we don't need to write a 7.3-specific patch for the
> >> > RSB as well) with a few additons (at least for the x86_64 target, to
> >> > try to have an empty bsp_specs to begin with).
> >> >
> >> > [1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
> >> > [2]
> >> > https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-
> compile-stub/bsps/x86_64/amd64/start/bsp_specs
> >> >
> >> > On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill 
> wrote:
> >> >> ---
> >> >>  gcc/config.gcc|  2 +-
> >> >>  gcc/config/arm/rtems.h|  4 
> >> >>  gcc/config/bfin/rtems.h   |  4 
> >> >>  gcc/config/i386/rtemself.h|  6 +-
> >> >>  gcc/config/i386/rtemself64.h  | 39
> >> >> +++
> >> >>  gcc/config/m68k/rtemself.h|  4 
> >> >>  gcc/config/microblaze/rtems.h |  4 
> >> >>  gcc/config/mips/rtems.h   |  4 
> >> >>  gcc/config/moxie/rtems.h  |  4 
> >> >>  gcc/config/nios2/rtems.h  |  4 
> >> >>  gcc/config/riscv/rtems.h  |  4 
> >> >>  gcc/config/rs6000/rtems.h |  5 +
> >> >>  gcc/config/rtems.h|  6 +-
> >> >>  gcc/config/sh/rtems.h |  4 
> >> >>  gcc/config/sh/rtemself.h  |  4 
> >> >>  gcc/config/sparc/rtemself.h   |  4 
> >> >>  gcc/config/v850/rtems.h   |  4 
> >> >>  17 files changed, 103 insertions(+), 3 deletions(-)
> >> >>  create mode 100644 gcc/config/i386/rtemself64.h
> >> >>
> >> >> diff --git a/gcc/config.gcc b/gcc/config.gcc
> >> >> index d509800..de27e5c 100644
> >> >> --- a/gcc/config.gcc
> >> >> +++ b/gcc/config.gcc
> >> >> @@ -1499,7 +1499,7 @@ x86_64-*-elf*)
> >> >> tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> >> >> newlib-stdint.h i386/i386elf.h i386/x86-64.h"
> >> >> ;;
> >> >>  x86_64-*-rtems*)
> >> >> -   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> >> >> newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself.h rtems.h"
> >> >> +   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> >> >> newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself64.h"
> >> >
> >> > In rebasing with upstream, this commit must have silently mistakenly
> >> > also dropped rtems.h (which my patch earlier added to support the
> >> > -qrtems, -qnolinkcmds, etc. flags).
> >> >
> >> >> ;;
> >> >>  i[34567]86-*-rdos*)
> >> >>  tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> >> >> newlib-stdint.h i386/i386elf.h i386/rdos.h"
> >> >> diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
> >> >> 

RTEMS Block Driver Execution Flow

[Joel Sherrill]

Hi

I am starting to write a block driver which doesn't have a media matching
any of the existing ones. I was trying to get a feel for the flow of
operations
and having trouble figuring it out. flashdisk looks to be a good guide
except
it is using rtems_disk_create_phys() which #3358 marks as deprecated.
RAM disk and NV disk still use it also.

Where's the best discussion of this?

 Any other guidance?

Thanks.

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

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

[Joel Sherrill]

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

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?

--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 02:29, Vijay Kumar Banerjee 
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
>
> and I'm getting this error :
>
> -
> ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
>
>
>
___
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 01:30, Cillian O'Donnell  wrote:

>
>
> On Fri, 18 May 2018, 14:55 Vijay Kumar Banerjee, 
> wrote:
>
>>
>>
>> On 18 May 2018 at 19:09, Cillian O'Donnell  wrote:
>>
>>>
>>>
>>> On Fri, 18 May 2018, 12:36 Vijay Kumar Banerjee, <
>>> vijaykumar9...@gmail.com> wrote:
>>>

 On 18 May 2018 at 12:30, Cillian O'Donnell 
 wrote:


> Cool, you should run it for the full testsuite and take a look at that
> report (takes a while.. around 575 tests)
>
>>
>>> When I try to run the full testsuites it gives the following error .
 What could be causing this ?

>>>
>>> If you run the full testsuite without the coverage options, does it
>>> still happen?
>>>
>> No it seems to run fine without coverage.
>>
>
> I vaguely remember seeing this before last year, I suspect that when
> things are cleared up in coverage.py it will dissappear. So don't worry
> about it for now, carry on with what you're doing. What branch are you
> working on at the moment?
>
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. 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

and I'm getting this error :

-
ERROR==> Different lengths for the symbol CSWTCH.1 (16 and 544)
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

[Amaan Cheval]

To be clear, I applied this patch (with my fixes) on the 7.3 release
through the RSB to test, not on GCC's master branch.

> to add i386/rtemself64.h

What you sent in this email thread adds rtemself64.h already. Do you
mean you'd like to split the commits up or something?

The only changes I made on top of yours were:

- Readd "rtems.h" to config.gcc
- Fix comments

I've attached the patch file I used within the RSB here (sorry if you
meant a patch of _just_ the fixes I made on top of yours, this is just
the cumulative diff I used to patch GCC 7.3 to test).

Regards,

On Fri, May 18, 2018 at 7:00 PM, Joel Sherrill  wrote:
>
>
>
> On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval 
> wrote:
>>
>> I just compiled my local fixed copy (adding rtems.h back in) and
>> there's good news! With the patch, the x86_64 compile stub works with
>> a blank bsp_specs file!
>
>
> Awesome!
>
> Can you send me your changes as a patch? I am thinking I need to make
> sure we agree on what the gcc master for x86_64-rtems looks like.
>
> Apparently I owe committing a patch to add i386/rtemself64.h since it is
> missing on the master. And the comment is wrong.  What else?
>
>> On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval 
>> wrote:
>> > Hey!
>> >
>> > Thanks so much for sharing this, it's quite useful to put your earlier
>> > email[1] about minimzing the bsp_specs in context.
>> >
>> > From looking ahead a bit without testing (still compiling), the patch
>> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it defines
>> > __TMC_END__ which crtbegin.o has left undefined for eg.) and possibly
>> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely
>> > (see here[2]).
>>
>> Just noticed that ENDFILE_SPEC already includes crtend in i386elf.h,
>> so there's no need for this change.
>>
>> >
>> > I've also left some comments inline below.
>> >
>> > +1 on upstreaming this into GCC (making sure it also backports to 7.3
>> > for simplicity, so we don't need to write a 7.3-specific patch for the
>> > RSB as well) with a few additons (at least for the x86_64 target, to
>> > try to have an empty bsp_specs to begin with).
>> >
>> > [1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
>> > [2]
>> > https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-compile-stub/bsps/x86_64/amd64/start/bsp_specs
>> >
>> > On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill  wrote:
>> >> ---
>> >>  gcc/config.gcc|  2 +-
>> >>  gcc/config/arm/rtems.h|  4 
>> >>  gcc/config/bfin/rtems.h   |  4 
>> >>  gcc/config/i386/rtemself.h|  6 +-
>> >>  gcc/config/i386/rtemself64.h  | 39
>> >> +++
>> >>  gcc/config/m68k/rtemself.h|  4 
>> >>  gcc/config/microblaze/rtems.h |  4 
>> >>  gcc/config/mips/rtems.h   |  4 
>> >>  gcc/config/moxie/rtems.h  |  4 
>> >>  gcc/config/nios2/rtems.h  |  4 
>> >>  gcc/config/riscv/rtems.h  |  4 
>> >>  gcc/config/rs6000/rtems.h |  5 +
>> >>  gcc/config/rtems.h|  6 +-
>> >>  gcc/config/sh/rtems.h |  4 
>> >>  gcc/config/sh/rtemself.h  |  4 
>> >>  gcc/config/sparc/rtemself.h   |  4 
>> >>  gcc/config/v850/rtems.h   |  4 
>> >>  17 files changed, 103 insertions(+), 3 deletions(-)
>> >>  create mode 100644 gcc/config/i386/rtemself64.h
>> >>
>> >> diff --git a/gcc/config.gcc b/gcc/config.gcc
>> >> index d509800..de27e5c 100644
>> >> --- a/gcc/config.gcc
>> >> +++ b/gcc/config.gcc
>> >> @@ -1499,7 +1499,7 @@ x86_64-*-elf*)
>> >> tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
>> >> newlib-stdint.h i386/i386elf.h i386/x86-64.h"
>> >> ;;
>> >>  x86_64-*-rtems*)
>> >> -   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
>> >> newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself.h rtems.h"
>> >> +   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
>> >> newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself64.h"
>> >
>> > In rebasing with upstream, this commit must have silently mistakenly
>> > also dropped rtems.h (which my patch earlier added to support the
>> > -qrtems, -qnolinkcmds, etc. flags).
>> >
>> >> ;;
>> >>  i[34567]86-*-rdos*)
>> >>  tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
>> >> newlib-stdint.h i386/i386elf.h i386/rdos.h"
>> >> diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
>> >> index 1123f4a..e79ce90 100644
>> >> --- a/gcc/config/arm/rtems.h
>> >> +++ b/gcc/config/arm/rtems.h
>> >> @@ -34,3 +34,7 @@
>> >>  } while (0)
>> >>
>> >>  #define ARM_DEFAULT_SHORT_ENUMS false
>> >> +
>> >> +#undef STARTFILE_SPEC
>> >> +#define STARTFILE_SPEC "\
>> >> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
>> >> diff --git a/gcc/config/bfin/rtems.h b/gcc/config/bfin/rtems.h
>> >> index 6a9a41f..28a69b9 100644
>> >> --- 

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

[Amaan Cheval]

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

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

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

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

[Cillian O'Donnell]

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

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

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

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

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

Re: Query regarding disk cache in RTEMS

[Udit agarwal]

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

> Udit,
>
> On Thu, May 17, 2018 at 9:13 AM, Udit agarwal 
> wrote:
> > Hi all,
> > I was looking at the internal working of a benchmark and the way it
> disables
> > cache for direct IO operations, needed to benchmark storage device
> drivers.
> > I have a small query regarding how cache is organized in RTEMS:
> >
> > Usually data transfer model is something like:
> > Application address space --> Page cache --> Write-back cache --> storage
> > device
> > is this model valid for RTEMS too?
> >
> > Moreover, in FreeBSD/Linux, O_DIRECT flag is used with the file
> descriptor
> > to bypass write-back cache. do we have something like that in RTEMS?
> AFAIK,
> > In RTEMS, libblock is used to transfer data to the storage device. So,
> > configuring it like:
> >>
> >>  #define CONFIGURE_BDBUF_MAX_READ_AHEAD_BLOCKS 0
> >
> > should disable the cache? or is there any other setting that should be
> > tweaked?
> >
>
> I think you are on the right path. We have bdbuf cache as the way to
> buffer block I/O operations. I don't know if that option is enough to
> turn off caching. You should check the user manual, and inspect the
> code.
>
> Sure, We also found that the page cache(that i mentioned up there) was
maintained in newlib itself and can be configured by setvbuf() command.

> > Regards,
> > Udit
> >
> >
> > ___
> > 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: LIST OF IO BENCHMARKS

[Gedare Bloom]

Udit,

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

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

Re: [PATCH] removed double 'with'

[Joel Sherrill]

Good eye! Thanks for the patch.

Committed.

On Fri, May 18, 2018 at 9:16 AM, Malte Münch  wrote:

> ---
>  c-user/configuring_a_system.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/c-user/configuring_a_system.rst
> b/c-user/configuring_a_system.rst
> index 2da9601..542a536 100644
> --- a/c-user/configuring_a_system.rst
> +++ b/c-user/configuring_a_system.rst
> @@ -45,7 +45,7 @@ appropriate. For example, by default there will be 256
> task priority levels but
>  this can be lowered by the application. This number of priority levels is
>  required to be compliant with the RTEID/ORKID standards upon which the
> Classic
>  API is based. There are similar cases where the default is selected to be
> -compliant with with the POSIX standard.
> +compliant with the POSIX standard.
>
>  For each configuration parameter in the configuration tables, the macro
>  corresponding to that field is discussed. The RTEMS Maintainers expect
> that all
> --
> 2.17.0
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] removed double 'with'

[Malte Münch]

---
 c-user/configuring_a_system.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst
index 2da9601..542a536 100644
--- a/c-user/configuring_a_system.rst
+++ b/c-user/configuring_a_system.rst
@@ -45,7 +45,7 @@ appropriate. For example, by default there will be 256 task 
priority levels but
 this can be lowered by the application. This number of priority levels is
 required to be compliant with the RTEID/ORKID standards upon which the Classic
 API is based. There are similar cases where the default is selected to be
-compliant with with the POSIX standard.
+compliant with the POSIX standard.
 
 For each configuration parameter in the configuration tables, the macro
 corresponding to that field is discussed. The RTEMS Maintainers expect that all
-- 
2.17.0

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

Re: [PATCH 01/16] beatnik: Move -Dxxx to configure.ac

[Joel Sherrill]

On Fri, May 18, 2018 at 8:44 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 18/05/18 15:42, Joel Sherrill wrote:
>
>>
>>
>> On Fri, May 18, 2018 at 8:25 AM, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de > ed-brains.de>> wrote:
>>
>> On 18/05/18 15:21, Joel Sherrill wrote:
>>
>>
>>
>> On Fri, May 18, 2018 at 12:41 AM, Sebastian Huber
>> > 
>> >
>> >> wrote:
>>
>> On 16/05/18 17:09, Joel Sherrill wrote:
>>
>> Updates #3425.
>> ---
>>   bsps/powerpc/beatnik/config/beatnik.cfg  | 2 +-
>>   c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> 
>>  | 2 ++
>>   2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/bsps/powerpc/beatnik/config/beatnik.cfg
>> b/bsps/powerpc/beatnik/config/beatnik.cfg
>> index 1190cad..05bea38 100644
>> --- a/bsps/powerpc/beatnik/config/beatnik.cfg
>> +++ b/bsps/powerpc/beatnik/config/beatnik.cfg
>> @@ -14,7 +14,7 @@ RTEMS_BSP_FAMILY=beatnik
>>   #  This contains the compiler options necessary to
>> select
>> the CPU model
>>   #  and (hopefully) optimize for it.
>>   #
>> -CPU_CFLAGS = -mcpu=7400 -D__ppc_generic
>> +CPU_CFLAGS = -mcpu=7400
>>   #T. Straumann; disable sdata=eabi for now until CEXP
>> supports it -meabi -msdata=eabi
>> # optimize flag: typically -0, could use -O4 or -fast
>> diff --git
>> a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> 
>> 
>> b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> 
>> 
>> index a48007c..b332aaa 100644
>> --- a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> 
>> 
>> +++ b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> 
>> 
>> @@ -34,6 +34,8 @@ Note that the policy can still be
>> defined by
>> the application
>>   CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is
>> removed
>>   and a little memory is saved.])
>>   +AC_DEFINE(__ppc_generic, 1, [PowerPC model option])
>> +
>>   # Explicitly list all Makefiles here
>>   AC_CONFIG_FILES([Makefile])
>>
>>
>> I would rather eliminate the only user of __ppc_generic in
>> bsps/powerpc/include/rtems/powerpc/powerpc.h.
>>
>>
>> I have file another ticket #3431 to address this and assigned
>> it to you.
>>
>> I am committing my changes because they eliminate use of -D on
>> the GCC command line
>> and allow packages using rtems_waf to compile.
>>
>>
>> Did you check that every consumer of these defines includes
>>  somehow?
>>
>>
>> powerpc.h fails to compile if it isn't provided.
>>
>
> Are these defines only used in powerpc.h?


$ grep -lr __ppc_generic .
./c/src/lib/libbsp/powerpc/beatnik/configure.ac
./c/src/lib/libbsp/powerpc/motorola_powerpc/configure.ac
./c/src/lib/libbsp/powerpc/mpc55xxevb/configure.ac
./c/src/lib/libbsp/powerpc/mvme3100/configure.ac
./c/src/lib/libbsp/powerpc/qoriq/configure.ac
./c/src/lib/libbsp/powerpc/t32mppc/configure.ac
./bsps/powerpc/include/rtems/powerpc/powerpc.h

I didn't check the others. If it broke something because
someone wasn't writing defensive enough ifdef's, then
that code should be fixed to be more defensive.

powerpc.h had a default to #error



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

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

[Vijay Kumar Banerjee]

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

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

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

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

Re: [PATCH 01/16] beatnik: Move -Dxxx to configure.ac

[Sebastian Huber]

On 18/05/18 15:42, Joel Sherrill wrote:



On Fri, May 18, 2018 at 8:25 AM, Sebastian Huber 
> wrote:


On 18/05/18 15:21, Joel Sherrill wrote:



On Fri, May 18, 2018 at 12:41 AM, Sebastian Huber

>> wrote:

    On 16/05/18 17:09, Joel Sherrill wrote:

        Updates #3425.
        ---
          bsps/powerpc/beatnik/config/beatnik.cfg      | 2 +-
          c/src/lib/libbsp/powerpc/beatnik/configure.ac

         | 2 ++
          2 files changed, 3 insertions(+), 1 deletion(-)

        diff --git a/bsps/powerpc/beatnik/config/beatnik.cfg
        b/bsps/powerpc/beatnik/config/beatnik.cfg
        index 1190cad..05bea38 100644
        --- a/bsps/powerpc/beatnik/config/beatnik.cfg
        +++ b/bsps/powerpc/beatnik/config/beatnik.cfg
        @@ -14,7 +14,7 @@ RTEMS_BSP_FAMILY=beatnik
          #  This contains the compiler options necessary to
select
        the CPU model
          #  and (hopefully) optimize for it.
          #
        -CPU_CFLAGS = -mcpu=7400 -D__ppc_generic
        +CPU_CFLAGS = -mcpu=7400
          #T. Straumann; disable sdata=eabi for now until CEXP
        supports it -meabi -msdata=eabi
            # optimize flag: typically -0, could use -O4 or -fast
        diff --git
a/c/src/lib/libbsp/powerpc/beatnik/configure.ac

        
        b/c/src/lib/libbsp/powerpc/beatnik/configure.ac

        
        index a48007c..b332aaa 100644
        --- a/c/src/lib/libbsp/powerpc/beatnik/configure.ac

        
        +++ b/c/src/lib/libbsp/powerpc/beatnik/configure.ac

        
        @@ -34,6 +34,8 @@ Note that the policy can still be
defined by
        the application
          CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is
removed
          and a little memory is saved.])
          +AC_DEFINE(__ppc_generic, 1, [PowerPC model option])
        +
          # Explicitly list all Makefiles here
          AC_CONFIG_FILES([Makefile])


    I would rather eliminate the only user of __ppc_generic in
    bsps/powerpc/include/rtems/powerpc/powerpc.h.


I have file another ticket #3431 to address this and assigned
it to you.

I am committing my changes because they eliminate use of -D on
the GCC command line
and allow packages using rtems_waf to compile.


Did you check that every consumer of these defines includes
 somehow?


powerpc.h fails to compile if it isn't provided.


Are these defines only used in powerpc.h?

--
Sebastian Huber, embedded brains GmbH

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

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

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

Re: [PATCH 01/16] beatnik: Move -Dxxx to configure.ac

[Joel Sherrill]

On Fri, May 18, 2018 at 8:25 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 18/05/18 15:21, Joel Sherrill wrote:
>
>>
>>
>> On Fri, May 18, 2018 at 12:41 AM, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de > ed-brains.de>> wrote:
>>
>> On 16/05/18 17:09, Joel Sherrill wrote:
>>
>> Updates #3425.
>> ---
>>   bsps/powerpc/beatnik/config/beatnik.cfg   | 2 +-
>>   c/src/lib/libbsp/powerpc/beatnik/configure.ac
>>  | 2 ++
>>   2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/bsps/powerpc/beatnik/config/beatnik.cfg
>> b/bsps/powerpc/beatnik/config/beatnik.cfg
>> index 1190cad..05bea38 100644
>> --- a/bsps/powerpc/beatnik/config/beatnik.cfg
>> +++ b/bsps/powerpc/beatnik/config/beatnik.cfg
>> @@ -14,7 +14,7 @@ RTEMS_BSP_FAMILY=beatnik
>>   #  This contains the compiler options necessary to select
>> the CPU model
>>   #  and (hopefully) optimize for it.
>>   #
>> -CPU_CFLAGS = -mcpu=7400 -D__ppc_generic
>> +CPU_CFLAGS = -mcpu=7400
>>   #T. Straumann; disable sdata=eabi for now until CEXP
>> supports it -meabi -msdata=eabi
>> # optimize flag: typically -0, could use -O4 or -fast
>> diff --git a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> 
>> b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> 
>> index a48007c..b332aaa 100644
>> --- a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> 
>> +++ b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> 
>> @@ -34,6 +34,8 @@ Note that the policy can still be defined by
>> the application
>>   CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
>>   and a little memory is saved.])
>>   +AC_DEFINE(__ppc_generic, 1, [PowerPC model option])
>> +
>>   # Explicitly list all Makefiles here
>>   AC_CONFIG_FILES([Makefile])
>>
>>
>> I would rather eliminate the only user of __ppc_generic in
>> bsps/powerpc/include/rtems/powerpc/powerpc.h.
>>
>>
>> I have file another ticket #3431 to address this and assigned it to you.
>>
>> I am committing my changes because they eliminate use of -D on the GCC
>> command line
>> and allow packages using rtems_waf to compile.
>>
>
> Did you check that every consumer of these defines includes 
> somehow?


powerpc.h fails to compile if it isn't provided.

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

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

[Cillian O'Donnell]

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

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

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

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

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

[Joel Sherrill]

On Fri, May 18, 2018 at 1:38 AM, Amaan Cheval 
wrote:

> I just compiled my local fixed copy (adding rtems.h back in) and
> there's good news! With the patch, the x86_64 compile stub works with
> a blank bsp_specs file!
>

Awesome!

Can you send me your changes as a patch? I am thinking I need to make
sure we agree on what the gcc master for x86_64-rtems looks like.

Apparently I owe committing a patch to add i386/rtemself64.h since it is
missing on the master. And the comment is wrong.  What else?

On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval 
> wrote:
> > Hey!
> >
> > Thanks so much for sharing this, it's quite useful to put your earlier
> > email[1] about minimzing the bsp_specs in context.
> >
> > From looking ahead a bit without testing (still compiling), the patch
> > may need an ENDFILE_SPEC definition as well for "crtend.o" (it defines
> > __TMC_END__ which crtbegin.o has left undefined for eg.) and possibly
> > "crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely
> > (see here[2]).
>
> Just noticed that ENDFILE_SPEC already includes crtend in i386elf.h,
> so there's no need for this change.
>
> >
> > I've also left some comments inline below.
> >
> > +1 on upstreaming this into GCC (making sure it also backports to 7.3
> > for simplicity, so we don't need to write a 7.3-specific patch for the
> > RSB as well) with a few additons (at least for the x86_64 target, to
> > try to have an empty bsp_specs to begin with).
> >
> > [1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
> > [2] https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-
> compile-stub/bsps/x86_64/amd64/start/bsp_specs
> >
> > On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill  wrote:
> >> ---
> >>  gcc/config.gcc|  2 +-
> >>  gcc/config/arm/rtems.h|  4 
> >>  gcc/config/bfin/rtems.h   |  4 
> >>  gcc/config/i386/rtemself.h|  6 +-
> >>  gcc/config/i386/rtemself64.h  | 39 ++
> +
> >>  gcc/config/m68k/rtemself.h|  4 
> >>  gcc/config/microblaze/rtems.h |  4 
> >>  gcc/config/mips/rtems.h   |  4 
> >>  gcc/config/moxie/rtems.h  |  4 
> >>  gcc/config/nios2/rtems.h  |  4 
> >>  gcc/config/riscv/rtems.h  |  4 
> >>  gcc/config/rs6000/rtems.h |  5 +
> >>  gcc/config/rtems.h|  6 +-
> >>  gcc/config/sh/rtems.h |  4 
> >>  gcc/config/sh/rtemself.h  |  4 
> >>  gcc/config/sparc/rtemself.h   |  4 
> >>  gcc/config/v850/rtems.h   |  4 
> >>  17 files changed, 103 insertions(+), 3 deletions(-)
> >>  create mode 100644 gcc/config/i386/rtemself64.h
> >>
> >> diff --git a/gcc/config.gcc b/gcc/config.gcc
> >> index d509800..de27e5c 100644
> >> --- a/gcc/config.gcc
> >> +++ b/gcc/config.gcc
> >> @@ -1499,7 +1499,7 @@ x86_64-*-elf*)
> >> tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> newlib-stdint.h i386/i386elf.h i386/x86-64.h"
> >> ;;
> >>  x86_64-*-rtems*)
> >> -   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself.h rtems.h"
> >> +   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself64.h"
> >
> > In rebasing with upstream, this commit must have silently mistakenly
> > also dropped rtems.h (which my patch earlier added to support the
> > -qrtems, -qnolinkcmds, etc. flags).
> >
> >> ;;
> >>  i[34567]86-*-rdos*)
> >>  tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h
> newlib-stdint.h i386/i386elf.h i386/rdos.h"
> >> diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
> >> index 1123f4a..e79ce90 100644
> >> --- a/gcc/config/arm/rtems.h
> >> +++ b/gcc/config/arm/rtems.h
> >> @@ -34,3 +34,7 @@
> >>  } while (0)
> >>
> >>  #define ARM_DEFAULT_SHORT_ENUMS false
> >> +
> >> +#undef STARTFILE_SPEC
> >> +#define STARTFILE_SPEC "\
> >> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
> >> diff --git a/gcc/config/bfin/rtems.h b/gcc/config/bfin/rtems.h
> >> index 6a9a41f..28a69b9 100644
> >> --- a/gcc/config/bfin/rtems.h
> >> +++ b/gcc/config/bfin/rtems.h
> >> @@ -31,3 +31,7 @@
> >>builtin_assert ("system=rtems"); \
> >>  }  \
> >>while (0)
> >> +
> >> +#undef STARTFILE_SPEC
> >> +#define STARTFILE_SPEC "\
> >> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
> >> diff --git a/gcc/config/i386/rtemself.h b/gcc/config/i386/rtemself.h
> >> index 65e8dad..3a09354 100644
> >> --- a/gcc/config/i386/rtemself.h
> >> +++ b/gcc/config/i386/rtemself.h
> >> @@ -1,4 +1,4 @@
> >> -/* Definitions for rtems targeting an ix86 using ELF.
> >> +/* Definitions for rtems targeting an x86_64 using ELF.
> >
> > I think you meant to have this comment in rtemself64.h, which says
> > ix86 currently?
> >
> >> Copyright (C) 

Re: [PATCH 01/16] beatnik: Move -Dxxx to configure.ac

[Sebastian Huber]

On 18/05/18 15:21, Joel Sherrill wrote:



On Fri, May 18, 2018 at 12:41 AM, Sebastian Huber 
> wrote:


On 16/05/18 17:09, Joel Sherrill wrote:

Updates #3425.
---
  bsps/powerpc/beatnik/config/beatnik.cfg       | 2 +-
  c/src/lib/libbsp/powerpc/beatnik/configure.ac
 | 2 ++
  2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/bsps/powerpc/beatnik/config/beatnik.cfg
b/bsps/powerpc/beatnik/config/beatnik.cfg
index 1190cad..05bea38 100644
--- a/bsps/powerpc/beatnik/config/beatnik.cfg
+++ b/bsps/powerpc/beatnik/config/beatnik.cfg
@@ -14,7 +14,7 @@ RTEMS_BSP_FAMILY=beatnik
  #  This contains the compiler options necessary to select
the CPU model
  #  and (hopefully) optimize for it.
  #
-CPU_CFLAGS = -mcpu=7400 -D__ppc_generic
+CPU_CFLAGS = -mcpu=7400
  #T. Straumann; disable sdata=eabi for now until CEXP
supports it -meabi -msdata=eabi
    # optimize flag: typically -0, could use -O4 or -fast
diff --git a/c/src/lib/libbsp/powerpc/beatnik/configure.ac

b/c/src/lib/libbsp/powerpc/beatnik/configure.ac

index a48007c..b332aaa 100644
--- a/c/src/lib/libbsp/powerpc/beatnik/configure.ac

+++ b/c/src/lib/libbsp/powerpc/beatnik/configure.ac

@@ -34,6 +34,8 @@ Note that the policy can still be defined by
the application
  CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
  and a little memory is saved.])
  +AC_DEFINE(__ppc_generic, 1, [PowerPC model option])
+
  # Explicitly list all Makefiles here
  AC_CONFIG_FILES([Makefile])


I would rather eliminate the only user of __ppc_generic in
bsps/powerpc/include/rtems/powerpc/powerpc.h.


I have file another ticket #3431 to address this and assigned it to you.

I am committing my changes because they eliminate use of -D on the GCC 
command line

and allow packages using rtems_waf to compile.


Did you check that every consumer of these defines includes  
somehow?


--
Sebastian Huber, embedded brains GmbH

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

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

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

Re: [PATCH 01/16] beatnik: Move -Dxxx to configure.ac

[Joel Sherrill]

On Fri, May 18, 2018 at 12:41 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 16/05/18 17:09, Joel Sherrill wrote:
>
>> Updates #3425.
>> ---
>>   bsps/powerpc/beatnik/config/beatnik.cfg   | 2 +-
>>   c/src/lib/libbsp/powerpc/beatnik/configure.ac | 2 ++
>>   2 files changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/bsps/powerpc/beatnik/config/beatnik.cfg
>> b/bsps/powerpc/beatnik/config/beatnik.cfg
>> index 1190cad..05bea38 100644
>> --- a/bsps/powerpc/beatnik/config/beatnik.cfg
>> +++ b/bsps/powerpc/beatnik/config/beatnik.cfg
>> @@ -14,7 +14,7 @@ RTEMS_BSP_FAMILY=beatnik
>>   #  This contains the compiler options necessary to select the CPU model
>>   #  and (hopefully) optimize for it.
>>   #
>> -CPU_CFLAGS = -mcpu=7400 -D__ppc_generic
>> +CPU_CFLAGS = -mcpu=7400
>>   #T. Straumann; disable sdata=eabi for now until CEXP supports it -meabi
>> -msdata=eabi
>> # optimize flag: typically -0, could use -O4 or -fast
>> diff --git a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> index a48007c..b332aaa 100644
>> --- a/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> +++ b/c/src/lib/libbsp/powerpc/beatnik/configure.ac
>> @@ -34,6 +34,8 @@ Note that the policy can still be defined by the
>> application
>>   CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK this feature is removed
>>   and a little memory is saved.])
>>   +AC_DEFINE(__ppc_generic, 1, [PowerPC model option])
>> +
>>   # Explicitly list all Makefiles here
>>   AC_CONFIG_FILES([Makefile])
>>
>>
>
> I would rather eliminate the only user of __ppc_generic in
> bsps/powerpc/include/rtems/powerpc/powerpc.h.


I have file another ticket #3431 to address this and assigned it to you.

I am committing my changes because they eliminate use of -D on the GCC
command line
and allow packages using rtems_waf to compile.

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

Re: [PATCH] fix typo: extesion->extension

[Sebastian Huber]

Thanks, I checked it in.

--
Sebastian Huber, embedded brains GmbH

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

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

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

[PATCH] fix typo: extesion->extension

[Malte Muench]

---
 c-user/fatal_error.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c-user/fatal_error.rst b/c-user/fatal_error.rst
index d8566f0..7945030 100644
--- a/c-user/fatal_error.rst
+++ b/c-user/fatal_error.rst
@@ -63,7 +63,7 @@ The fatal error handler in the static extension set can be 
used to provide
 access to debuggers and monitors which may be present on the target hardware.
 If any user-supplied fatal error handlers are installed, the fatal error
 manager will invoke them.  Usually, the board support package provides a fatal
-error extesion which resets the board.  If no user handlers are configured or
+error extension which resets the board.  If no user handlers are configured or
 if all the user handler return control to the fatal error manager, then the
 RTEMS default fatal error handler is invoked.  If the default fatal error
 handler is invoked, then the system state is marked as failed.
-- 
2.17.0

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

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

Re: [PATCH] updated chapter references in chapter 2 of c-user doc.

[Chris Johns]

> On 18 May 2018, at 6:11 pm, Sebastian Huber 
>  wrote:
> 
> This stuff in
> 
> https://docs.rtems.org/branches/master/c-user/overview.html#manual-organization
> 
> looks hard to maintain.

I have not had a chance to see if this can be automated. 

> What is the value for the user? There are no real links in this section.

I think this section could be less specific, the chapter details are not 
needed, and more generic about the sections of interest, for example 
configuration, errors, SMP, scheduling, etc. 

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

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

[Cillian O'Donnell]

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

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

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

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

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

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

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

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

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

[Vijay Kumar Banerjee]

On Fri, 18 May 2018, 11:52 Cillian O'Donnell,  wrote:

>
>
> On Thu, 17 May 2018, 21:32 Vijay Kumar Banerjee, 
> wrote:
>
>> hello,
>>
>> I have attached the html report !
>>
>
> Report looks good! Well done. Was that just for samples. Did the other
> sections appear in the report if you click through the links?
>
yes it was for samples and yes the links are working .

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

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

Re: [PATCH] Rework to minimize and eventually eliminate RTEMS use of bsp_specs

[Amaan Cheval]

I just compiled my local fixed copy (adding rtems.h back in) and
there's good news! With the patch, the x86_64 compile stub works with
a blank bsp_specs file!

On Fri, May 18, 2018 at 12:59 AM, Amaan Cheval  wrote:
> Hey!
>
> Thanks so much for sharing this, it's quite useful to put your earlier
> email[1] about minimzing the bsp_specs in context.
>
> From looking ahead a bit without testing (still compiling), the patch
> may need an ENDFILE_SPEC definition as well for "crtend.o" (it defines
> __TMC_END__ which crtbegin.o has left undefined for eg.) and possibly
> "crtn.o", at least to eliminate the x86_64 port's bsp_specs entirely
> (see here[2]).

Just noticed that ENDFILE_SPEC already includes crtend in i386elf.h,
so there's no need for this change.

>
> I've also left some comments inline below.
>
> +1 on upstreaming this into GCC (making sure it also backports to 7.3
> for simplicity, so we don't need to write a 7.3-specific patch for the
> RSB as well) with a few additons (at least for the x86_64 target, to
> try to have an empty bsp_specs to begin with).
>
> [1] https://lists.rtems.org/pipermail/devel/2018-May/021430.html
> [2] 
> https://github.com/AmaanC/rtems-gsoc18/blob/ac/daily-01-compile-stub/bsps/x86_64/amd64/start/bsp_specs
>
> On Wed, May 16, 2018 at 8:46 PM, Joel Sherrill  wrote:
>> ---
>>  gcc/config.gcc|  2 +-
>>  gcc/config/arm/rtems.h|  4 
>>  gcc/config/bfin/rtems.h   |  4 
>>  gcc/config/i386/rtemself.h|  6 +-
>>  gcc/config/i386/rtemself64.h  | 39 +++
>>  gcc/config/m68k/rtemself.h|  4 
>>  gcc/config/microblaze/rtems.h |  4 
>>  gcc/config/mips/rtems.h   |  4 
>>  gcc/config/moxie/rtems.h  |  4 
>>  gcc/config/nios2/rtems.h  |  4 
>>  gcc/config/riscv/rtems.h  |  4 
>>  gcc/config/rs6000/rtems.h |  5 +
>>  gcc/config/rtems.h|  6 +-
>>  gcc/config/sh/rtems.h |  4 
>>  gcc/config/sh/rtemself.h  |  4 
>>  gcc/config/sparc/rtemself.h   |  4 
>>  gcc/config/v850/rtems.h   |  4 
>>  17 files changed, 103 insertions(+), 3 deletions(-)
>>  create mode 100644 gcc/config/i386/rtemself64.h
>>
>> diff --git a/gcc/config.gcc b/gcc/config.gcc
>> index d509800..de27e5c 100644
>> --- a/gcc/config.gcc
>> +++ b/gcc/config.gcc
>> @@ -1499,7 +1499,7 @@ x86_64-*-elf*)
>> tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
>> newlib-stdint.h i386/i386elf.h i386/x86-64.h"
>> ;;
>>  x86_64-*-rtems*)
>> -   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
>> newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself.h rtems.h"
>> +   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
>> newlib-stdint.h i386/i386elf.h i386/x86-64.h i386/rtemself64.h"
>
> In rebasing with upstream, this commit must have silently mistakenly
> also dropped rtems.h (which my patch earlier added to support the
> -qrtems, -qnolinkcmds, etc. flags).
>
>> ;;
>>  i[34567]86-*-rdos*)
>>  tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
>> newlib-stdint.h i386/i386elf.h i386/rdos.h"
>> diff --git a/gcc/config/arm/rtems.h b/gcc/config/arm/rtems.h
>> index 1123f4a..e79ce90 100644
>> --- a/gcc/config/arm/rtems.h
>> +++ b/gcc/config/arm/rtems.h
>> @@ -34,3 +34,7 @@
>>  } while (0)
>>
>>  #define ARM_DEFAULT_SHORT_ENUMS false
>> +
>> +#undef STARTFILE_SPEC
>> +#define STARTFILE_SPEC "\
>> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
>> diff --git a/gcc/config/bfin/rtems.h b/gcc/config/bfin/rtems.h
>> index 6a9a41f..28a69b9 100644
>> --- a/gcc/config/bfin/rtems.h
>> +++ b/gcc/config/bfin/rtems.h
>> @@ -31,3 +31,7 @@
>>builtin_assert ("system=rtems"); \
>>  }  \
>>while (0)
>> +
>> +#undef STARTFILE_SPEC
>> +#define STARTFILE_SPEC "\
>> +%{!nostdlib: %{!qrtems: crt0.o%s} crti.o%s crtbegin.o%s}"
>> diff --git a/gcc/config/i386/rtemself.h b/gcc/config/i386/rtemself.h
>> index 65e8dad..3a09354 100644
>> --- a/gcc/config/i386/rtemself.h
>> +++ b/gcc/config/i386/rtemself.h
>> @@ -1,4 +1,4 @@
>> -/* Definitions for rtems targeting an ix86 using ELF.
>> +/* Definitions for rtems targeting an x86_64 using ELF.
>
> I think you meant to have this comment in rtemself64.h, which says
> ix86 currently?
>
>> Copyright (C) 1996-2018 Free Software Foundation, Inc.
>> Contributed by Joel Sherrill (j...@oarcorp.com).
>>
>> @@ -33,3 +33,7 @@
>> builtin_assert ("system=rtems");\
>>  }  \
>>while (0)
>> +
>> +#undef STARTFILE_SPEC
>> +#define STARTFILE_SPEC "\
>> +%{!nostdlib: %{!qrtems: crt0.o%s} crtbegin.o%s}"
>> diff --git a/gcc/config/i386/rtemself64.h b/gcc/config/i386/rtemself64.h
>> new file mode 100644
>> index 000..34e5937
>> --- /dev/null
>> +++ b/gcc/config/i386/rtemself64.h
>> @@ -0,0 +1,39 @@
>> +/* 

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

[Cillian O'Donnell]

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

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

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

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

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

--coverage=score,core..etc

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

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

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

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

Re: [PATCH] updated chapter references in chapter 2 of c-user doc.

[Sebastian Huber]

Thanks, I checked in a slightly modified patch. Please keep the format 
of the original content, e.g. spaces instead of tabs, no white space at 
the end of the line.


This stuff in

https://docs.rtems.org/branches/master/c-user/overview.html#manual-organization

looks hard to maintain. What is the value for the user? There are no 
real links in this section.


--
Sebastian Huber, embedded brains GmbH

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

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

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