RE: dynamic checking tools

I'm not sure about tools similar to valgrind, but you might find it useful to enable deep memory tests in RTEMS. You can find more information here. http://www.rtems.org/wiki/index.php/Debugging#Optional_Compile-time_Selections By enabling these macros you can check if your memory is getting corr

Re: dynamic checking tools

On 18/09/2014 4:01 am, Daniel Gutson wrote: are there any dynamic checking tools (a la valgrind/helgrind/memcheck/drd and *sanitizer) for RTEMS? More specifically, I'm interested in memory and concurrency checking, more specifically for ARM. None that I know of. My limited understanding o

Re: rtems capture: ctload and stack usage functionality

On 18/09/2014 3:30 am, Jennifer Averett wrote: Are there any objections to getting rid of the cpu usage and the stack checking capability in the capture engine. I think rtems cpu usage and rtems stack checker should be used instead. Keeping this information in the capture engine seems redunda

Re: Separation of RTEMS sources and tool chain patches

On 17/09/2014 6:49 pm, Sebastian Huber wrote: currently the RTEMS sources contain no reference to the intended tool chain versions (Binutils, Newlib, GCC, GDB) and patches for the tools. This is specified elsewhere, for example in the RTEMS tools repository. The RSB has the ability to report

Re: or1k test was .. Re: [PATCH] or1k: New cache manager.

On 9/17/2014 2:48 PM, Hesham Moustafa wrote: > > On Wed, Sep 17, 2014 at 9:44 PM, Joel Sherrill > wrote: > > > On 9/17/2014 12:44 PM, Hesham Moustafa wrote: > > > > On Tue, Sep 16, 2014 at 11:08 PM, Joel Sherrill > mailto:joel.sherr...@oarcorp.com> >

Re: Single Warning Analysis Request

Thanks, I will look into it. On Wed, Sep 17, 2014 at 4:02 PM, Joel Sherrill wrote: > > On 9/17/2014 1:38 PM, Marcos Díaz wrote: >> Where can we see in which BSP's and with which tools this warning was >> generated? Thanks > OK. It is with the tools generated by the current RSB and > the RTEMS he

Re: or1k test was .. Re: [PATCH] or1k: New cache manager.

On Wed, Sep 17, 2014 at 9:44 PM, Joel Sherrill wrote: > > On 9/17/2014 12:44 PM, Hesham Moustafa wrote: > > > > On Tue, Sep 16, 2014 at 11:08 PM, Joel Sherrill < > joel.sherr...@oarcorp.com > > > wrote: > > > > Gedare.. cc'ed you for help in spotting an empty

Re: or1k test was .. Re: [PATCH] or1k: New cache manager.

On 9/17/2014 12:44 PM, Hesham Moustafa wrote: > > On Tue, Sep 16, 2014 at 11:08 PM, Joel Sherrill > wrote: > > Gedare.. cc'ed you for help in spotting an empty rbtree > in gdb. See below. > On 9/16/2014 2:45 PM, Hesham Moustafa wrote: > > Breakpo

Re: Single Warning Analysis Request

On 9/17/2014 1:38 PM, Marcos Díaz wrote: > Where can we see in which BSP's and with which tools this warning was > generated? Thanks OK. It is with the tools generated by the current RSB and the RTEMS head. I have attached a cut down and script that I used to test it on all RTEMS gcc's I have i

Re: Single Warning Analysis Request

Where can we see in which BSP's and with which tools this warning was generated? Thanks On Wed, Sep 17, 2014 at 12:40 PM, Joel Sherrill wrote: > > On 9/17/2014 10:23 AM, Daniel Gutson wrote: >> Marcos and I will take a look. > Thanks. >> >> On Wed, Sep 17, 2014 at 12:19 PM, Joel Sherrill >> wrot

dynamic checking tools

Hi guys, are there any dynamic checking tools (a la valgrind/helgrind/memcheck/drd and *sanitizer) for RTEMS? More specifically, I'm interested in memory and concurrency checking, more specifically for ARM. Thanks! Daniel. -- Daniel F. Gutson Chief Engineering Officer, SPD San Lorenzo

Re: or1k test was .. Re: [PATCH] or1k: New cache manager.

On Tue, Sep 16, 2014 at 11:08 PM, Joel Sherrill wrote: > Gedare.. cc'ed you for help in spotting an empty rbtree > in gdb. See below. > On 9/16/2014 2:45 PM, Hesham Moustafa wrote: > > Breakpoint 2, 0x0600 in _unalign () > > (gdb) bt > > #0 0x0600 in _unalign () > > #1 0x0002ec4c in _RB

rtems capture: ctload and stack usage functionality

Are there any objections to getting rid of the cpu usage and the stack checking capability in the capture engine. I think rtems cpu usage and rtems stack checker should be used instead. Keeping this information in the capture engine seems redundant and this minimizes information that has to be k

Re: [PATCH] RTEMS: Update contrib/config-list.mk

On 9/17/2014 10:41 AM, Sebastian Huber wrote: > On 09/17/2014 04:45 PM, Jan-Benedict Glaw wrote: >> On Wed, 2014-09-17 15:37:32 +0200, Sebastian >> Huber wrote: contrib/ChangeLog 2014-09-17 Sebastian Huber * config-list.mk (LIST): Add arm-rtems. Add nios2-rtems.

Re: [PATCH] RTEMS: Update contrib/config-list.mk

On 09/17/2014 04:45 PM, Jan-Benedict Glaw wrote: On Wed, 2014-09-17 15:37:32 +0200, Sebastian Huber wrote: >contrib/ChangeLog >2014-09-17 Sebastian Huber > >* config-list.mk (LIST): Add arm-rtems. >Add nios2-rtems. Remove extra option from powerpc-rtems. What's the rationale for rem

Re: Single Warning Analysis Request

On 9/17/2014 10:23 AM, Daniel Gutson wrote: > Marcos and I will take a look. Thanks. > > On Wed, Sep 17, 2014 at 12:19 PM, Joel Sherrill > wrote: >> Hi >> >> I would really appreciate it if someone could look into this >> warning and see if we can get an explanation. It could be >> a source code

Re: Single Warning Analysis Request

Marcos and I will take a look. On Wed, Sep 17, 2014 at 12:19 PM, Joel Sherrill wrote: > Hi > > I would really appreciate it if someone could look into this > warning and see if we can get an explanation. It could be > a source code issue or something higher in the tools. > It is reported on 120 B

LEON3 Warning Status

Hi We are down to 6 warnings on the SPARC/LEON3 BSP with networking disabled. It would be awesome if these could be eliminated. ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/sparc/sparcv8-atomic.c:106:6: warning: conflicting types for built-in function '__atomic_compare_exchange_4' [

Single Warning Analysis Request

Hi I would really appreciate it if someone could look into this warning and see if we can get an explanation. It could be a source code issue or something higher in the tools. It is reported on 120 BSP build configurations: ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/hexdump-conv.c:1

Re: [PATCH] RTEMS: Update contrib/config-list.mk

Is there anyone else from GCC who needs to approve this? As RTEMS maintainer for GCC, I am ok with it. --joel On 9/17/2014 8:37 AM, Sebastian Huber wrote: > contrib/ChangeLog > 2014-09-17 Sebastian Huber > > * config-list.mk (LIST): Add arm-rtems. > Add nios2-rtems. Remove extra

Re: [PATCH] RTEMS thread model configuration

Thanks for the ping. I updated the date on the ChangeLog and committed this. --joel On 9/17/2014 8:26 AM, Sebastian Huber wrote: Ping^2. On 02/05/14 10:46, Sebastian Huber wrote: Ping. On 2014-04-18 12:11, Sebastian Huber wrote: From: Sebastian Huber The command line to build a GCC for

[PATCH] RTEMS: Update contrib/config-list.mk

contrib/ChangeLog 2014-09-17 Sebastian Huber * config-list.mk (LIST): Add arm-rtems. Add nios2-rtems. Remove extra option from powerpc-rtems. --- contrib/config-list.mk | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/contrib/config-list.mk b/contrib/c

Re: [PATCH] RTEMS thread model configuration

Ping^2. On 02/05/14 10:46, Sebastian Huber wrote: Ping. On 2014-04-18 12:11, Sebastian Huber wrote: From: Sebastian Huber The command line to build a GCC for RTEMS contained virtually always a '--enable-threads'. This patch helps to avoid this extra configuration command line parameter and

Separation of RTEMS sources and tool chain patches

Hello, currently the RTEMS sources contain no reference to the intended tool chain versions (Binutils, Newlib, GCC, GDB) and patches for the tools. This is specified elsewhere, for example in the RTEMS tools repository. Since the RTEMS version is tightly coupled to a particular tool chain ve