Discussions among eCos developers

Ilija Kocho | 13 Jan 2012 18:00

Gnutools: consideration for upgrade to GCC 4.6

Hi colleagues

Our GCC 4.3.2 is ageing and perhaps we should consider an upgrade.
My motive is it's lacking of support for Cortex-M4 SIMD (aka DSP) and 
FPU instructions, but I think that other architectures shall gain from 
newer compiler too. I have made some signal processing tests with GCC 
4.6.2 against current eCos compiler and they show performance gain even 
with Cortex-M3 setting, though moderate. Performance is considerable 
when Cortex-M4 setting is selected and is tremendous, as expected, when 
SIMD are used. Recently introduced Cortex-M products with FPU (Kinetis 
K70, K61, STM32F4) will further emphasise the benefit.

Another reason, maybe not so important, is that GCC 4.3 is not 
officially supported any more.

Regarding this, I state my wish that we move to the latest stable GCC 
release, that is at present rel. 4.6.2, accompanied with respective 
binutils. I have tested binutils 2.21 but in meantime 2.22 has been 
released. Of course, the list wouldn't be complete without the latest GDB.

Looking forward for your comments.
Ilija

headers

Bernard Fouché | 13 Jan 2012 19:54

Re: Gnutools: consideration for upgrade to GCC 4.6


Le 13/01/2012 18:00, Ilija Kocho a écrit :
>
> Our GCC 4.3.2 is ageing and perhaps we should consider an upgrade.
> My motive is it's lacking of support for Cortex-M4 SIMD (aka DSP) and 
> FPU instructions, but I think that other architectures shall gain from 
> newer compiler too. I have made some signal processing tests with GCC 
> 4.6.2 against current eCos compiler and they show performance gain 
> even with Cortex-M3 setting, though moderate. Performance is 
> considerable when Cortex-M4 setting is selected and is tremendous, as 
> expected, when SIMD are used. Recently introduced Cortex-M products 
> with FPU (Kinetis K70, K61, STM32F4) will further emphasise the benefit.
>
That sounds good! Did you try link time optimization ? I'm curious what 
kind of gain it could bring with a real world app. eCos seems to fit 
perfectly for such an optimization, there is no shared lib and at link 
time everythink is visible to the linker.

headers

Ilija Kocho | 13 Jan 2012 20:38

Re: Gnutools: consideration for upgrade to GCC 4.6

On 13.01.2012 19:54, Bernard Fouché wrote:
>
> Le 13/01/2012 18:00, Ilija Kocho a écrit :
>>
>> Our GCC 4.3.2 is ageing and perhaps we should consider an upgrade.
>> My motive is it's lacking of support for Cortex-M4 SIMD (aka DSP) and 
>> FPU instructions, but I think that other architectures shall gain 
>> from newer compiler too. I have made some signal processing tests 
>> with GCC 4.6.2 against current eCos compiler and they show 
>> performance gain even with Cortex-M3 setting, though moderate. 
>> Performance is considerable when Cortex-M4 setting is selected and is 
>> tremendous, as expected, when SIMD are used. Recently introduced 
>> Cortex-M products with FPU (Kinetis K70, K61, STM32F4) will further 
>> emphasise the benefit.
>>
> That sounds good! Did you try link time optimization ?

I haven't changed any option except -mcpu=cortex-m4. My objective were 
SIMD instructions (now with K70 FPU).

> I'm curious what kind of gain it could bring with a real world app. 
> eCos seems to fit perfectly for such an optimization, there is no 
> shared lib and at link time everythink is visible to the linker.

Worth to try.

Ilija

headers

Frank Pagliughi | 13 Jan 2012 20:09

Re: Gnutools: consideration for upgrade to GCC 4.6

On 01/13/2012 12:00 PM, Ilija Kocho wrote:
> Hi colleagues
>
> Our GCC 4.3.2 is ageing and perhaps we should consider an upgrade.
> My motive is it's lacking of support for Cortex-M4 SIMD (aka DSP) and 
> FPU instructions, but I think that other architectures shall gain from 
> newer compiler too. I have made some signal processing tests with GCC 
> 4.6.2 against current eCos compiler and they show performance gain 
> even with Cortex-M3 setting, though moderate. Performance is 
> considerable when Cortex-M4 setting is selected and is tremendous, as 
> expected, when SIMD are used. Recently introduced Cortex-M products 
> with FPU (Kinetis K70, K61, STM32F4) will further emphasise the benefit.
>
> Another reason, maybe not so important, is that GCC 4.3 is not 
> officially supported any more.
>
> Regarding this, I state my wish that we move to the latest stable GCC 
> release, that is at present rel. 4.6.2, accompanied with respective 
> binutils. I have tested binutils 2.21 but in meantime 2.22 has been 
> released. Of course, the list wouldn't be complete without the latest 
> GDB.
>
> Looking forward for your comments.
> Ilija
>
I'm all for it. I've been using 4.6.2 for the last few months for ARM 
(EABI, of course) and i386. The 4.3 compilers wouldn't compile some of 
the libraries that I use and I didn't want to back port them to an old 
compiler. I used binutils 2.21.1.

(Continue reading)

headers

Ilija Kocho | 13 Jan 2012 20:45

Re: Gnutools: consideration for upgrade to GCC 4.6

On 13.01.2012 20:09, Frank Pagliughi wrote:
> On 01/13/2012 12:00 PM, Ilija Kocho wrote:
>> Hi colleagues
>>
>> Our GCC 4.3.2 is ageing and perhaps we should consider an upgrade.
>> My motive is it's lacking of support for Cortex-M4 SIMD (aka DSP) and 
>> FPU instructions, but I think that other architectures shall gain 
>> from newer compiler too. I have made some signal processing tests 
>> with GCC 4.6.2 against current eCos compiler and they show 
>> performance gain even with Cortex-M3 setting, though moderate. 
>> Performance is considerable when Cortex-M4 setting is selected and is 
>> tremendous, as expected, when SIMD are used. Recently introduced 
>> Cortex-M products with FPU (Kinetis K70, K61, STM32F4) will further 
>> emphasise the benefit.
>>
>> Another reason, maybe not so important, is that GCC 4.3 is not 
>> officially supported any more.
>>
>> Regarding this, I state my wish that we move to the latest stable GCC 
>> release, that is at present rel. 4.6.2, accompanied with respective 
>> binutils. I have tested binutils 2.21 but in meantime 2.22 has been 
>> released. Of course, the list wouldn't be complete without the latest 
>> GDB.
>>
>> Looking forward for your comments.
>> Ilija
>>
> I'm all for it. I've been using 4.6.2 for the last few months for ARM 
> (EABI, of course) and i386. The 4.3 compilers wouldn't compile some of 
> the libraries that I use and I didn't want to back port them to an old

(Continue reading)

headers

John Dallaway | 14 Jan 2012 11:22

Re: Gnutools: consideration for upgrade to GCC 4.6

Hi Ilija and all

Ilija Kocho wrote:

> Our GCC 4.3.2 is ageing and perhaps we should consider an upgrade.
> My motive is it's lacking of support for Cortex-M4 SIMD (aka DSP) and
> FPU instructions, but I think that other architectures shall gain from
> newer compiler too. I have made some signal processing tests with GCC
> 4.6.2 against current eCos compiler and they show performance gain even
> with Cortex-M3 setting, though moderate. Performance is considerable
> when Cortex-M4 setting is selected and is tremendous, as expected, when
> SIMD are used. Recently introduced Cortex-M products with FPU (Kinetis
> K70, K61, STM32F4) will further emphasise the benefit.
> 
> Another reason, maybe not so important, is that GCC 4.3 is not
> officially supported any more.
> 
> Regarding this, I state my wish that we move to the latest stable GCC
> release, that is at present rel. 4.6.2, accompanied with respective
> binutils. I have tested binutils 2.21 but in meantime 2.22 has been
> released. Of course, the list wouldn't be complete without the latest GDB.

Moving to a more recent GCC makes sense to me.

There are sure to be some new compiler warnings to deal with in the eCos
sources. Are you aware of the scale of this issue with eCos CVS and GCC
4.6.2?

There are a few patches that were applied to current toolchain sources:

(Continue reading)

headers

Sergei Gavrikov | 14 Jan 2012 17:01

Re: Gnutools: consideration for upgrade to GCC 4.6

Hi all,

John Dallaway wrote:

> Hi Ilija and all
> 
> Ilija Kocho wrote:
> 
> > Our GCC 4.3.2 is ageing and perhaps we should consider an upgrade.
> > My motive is it's lacking of support for Cortex-M4 SIMD (aka DSP)
> > and FPU instructions, but I think that other architectures shall
> > gain from newer compiler too. I have made some signal processing
> > tests with GCC 4.6.2 against current eCos compiler and they show
> > performance gain even with Cortex-M3 setting, though moderate.
> > Performance is considerable when Cortex-M4 setting is selected and
> > is tremendous, as expected, when SIMD are used. Recently introduced
> > Cortex-M products with FPU (Kinetis K70, K61, STM32F4) will further
> > emphasise the benefit.
> > 
> > Another reason, maybe not so important, is that GCC 4.3 is not
> > officially supported any more.
> > 
> > Regarding this, I state my wish that we move to the latest stable
> > GCC release, that is at present rel. 4.6.2, accompanied with
> > respective binutils. I have tested binutils 2.21 but in meantime
> > 2.22 has been released. Of course, the list wouldn't be complete
> > without the latest GDB.
> 
> Moving to a more recent GCC makes sense to me.
>

(Continue reading)

headers

Grant Edwards | 15 Jan 2012 18:36

Re: Gnutools: consideration for upgrade to GCC 4.6

On 2012-01-14, Sergei Gavrikov <sergei.gavrikov <at> gmail.com> wrote:

> By the way I like their built-in __rtems__ definition for own GCC builds
> and I guess in the end we would propagate __ecos__ for own ones on the
> occasion of renewal.

Why?

Are the eCos sources going to start requiring use of specific
toolchain binaries?

I've been using eCos for a long time, and have always used my own
toolchains.  I'd be pretty unhappy if that was no longer possible.

--

-- 
Grant

headers

Sergei Gavrikov | 15 Jan 2012 19:42

Re: Gnutools: consideration for upgrade to GCC 4.6

On Sun, 15 Jan 2012, Grant Edwards wrote:

> On 2012-01-14, Sergei Gavrikov <sergei.gavrikov <at> gmail.com> wrote:
> 
> > By the way I like their built-in __rtems__ definition for own GCC builds
> > and I guess in the end we would propagate __ecos__ for own ones on the
> > occasion of renewal.
> 
> Why?

Simply to distinguish the official releases of toolchains (I hope well
tested) and any home-cooked toolchains. I meant such predefined things
for GCC (CPP)

  % i386-rtems4.11-gcc -dM -E - </dev/null | grep __rtems__
  #define __rtems__ 1

and the same we could have for officially supported releases for ecos,
e.g.

  % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
  #define __ecos__ 1

Secondly, it lets anyone to use such checks in sources, e.g.

  #if __linux__
  # include <endian.h>
  #elif __ecos__
  # include <machine/endian.h>
  #else

(Continue reading)

headers

Stanislav Meduna | 15 Jan 2012 22:39

Re: Gnutools: consideration for upgrade to GCC 4.6

On 15.01.2012 19:42, Sergei Gavrikov wrote:

> Secondly, it lets anyone to use such checks in sources, e.g.
>
>   #if __linux__
>   # include <endian.h>
>   #elif __ecos__
>   # include <machine/endian.h>
>   #else
>   ...
>   #endif

Doing this would break compatibility with older toolchain -
easily fixable (just add another -D... to global CFLAGS),
but nevertheless something every user has to explicitely
address. I don't know what the eCos policy for this kind
of changes is.

I am not strictly against this move (although I am also using
self-compiled toolchains); the question is what does it bring
to the user.

> The third, Why we should avoid to say that eCos is also well known,
> widely used OS?
> ...
> Look on that as a promotion eCos OS.

Does the specification of a target OS belong to a compiler at all?
Is there anything the compiler itself does differently for eCos
than for Linux or RTEMS (that is not covered by other flags)?

(Continue reading)

headers

Jonathan Larmour | 23 Jan 2012 02:00

Re: Gnutools: consideration for upgrade to GCC 4.6

On 15/01/12 21:39, Stanislav Meduna wrote:
> 
>> The third, Why we should avoid to say that eCos is also well known,
>> widely used OS?
>> ...
>> Look on that as a promotion eCos OS.
> 
> Does the specification of a target OS belong to a compiler at all?
> Is there anything the compiler itself does differently for eCos
> than for Linux or RTEMS (that is not covered by other flags)?
> If yes, go ahead. If not, frankly, I think that 'promotion' or
> 'others do it' is a bogus reason for hardcoding something into
> a compiler binary, so I'd only do this if there is a technical
> reason for it (IMHO of course).

Yes there are things the compiler does differently depending on the
runtime it's built with, but the compiler expects something that looks
like newlib, and eCos is close enough to that in enough ways that it
doesn't matter.

Jifl

headers

Ilija Kocho | 15 Jan 2012 23:20

Re: Gnutools: consideration for upgrade to GCC 4.6

On 15.01.2012 19:42, Sergei Gavrikov wrote:
> On Sun, 15 Jan 2012, Grant Edwards wrote:
>
>> On 2012-01-14, Sergei Gavrikov<sergei.gavrikov <at> gmail.com>  wrote:
>>
>>> By the way I like their built-in __rtems__ definition for own GCC builds
>>> and I guess in the end we would propagate __ecos__ for own ones on the
>>> occasion of renewal.
>> Why?
> Simply to distinguish the official releases of toolchains (I hope well
> tested) and any home-cooked toolchains. I meant such predefined things
> for GCC (CPP)
>
>    % i386-rtems4.11-gcc -dM -E -</dev/null | grep __rtems__
>    #define __rtems__ 1
>
> and the same we could have for officially supported releases for ecos,
> e.g.
>
>    % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
>    #define __ecos__ 1
>
> Secondly, it lets anyone to use such checks in sources, e.g.
>
>    #if __linux__
>    # include<endian.h>
>    #elif __ecos__
>    # include<machine/endian.h>
>    #else
>    ...

(Continue reading)

headers

Jonathan Larmour | 23 Jan 2012 02:07

Re: Gnutools: consideration for upgrade to GCC 4.6

On 15/01/12 22:20, Ilija Kocho wrote:
> On 15.01.2012 19:42, Sergei Gavrikov wrote:
[eCos specific toolchains]
> It seems there have been some attempts before as there are some traces
> left in gcc tree:
> gcc/config/arm/ecos-elf.h

That was Nick Clifton trying to be helpful to me years ago when he got the
wrong end of the stick about a conversation we had. It's not and never has
been used. I would ask them to remove it but don't quite feel it's worth
the effort for someone to take the time even to remove.

> I'm not sure about former addition, But IMO that it would be good to add
> t-ecos target description(s). The material is present in eCos patches
> ftp://ecos.sourceware.org/pub/ecos/gnutools/src/ .

IMHO I disagree.

>>> Are the eCos sources going to start requiring use of specific
>>> toolchain binaries?
>> Nope. Anyone can use own binaries if he/she wants.
> 
> We must be sure of this. People will need, from various reasons, to use
> different toolchains (commercial or self built).

In which case there's no point putting ecos in the target name.

There may well be a point when there is a real tangible technical benefit
that overrides the drawbacks. But until then we should not artificially
make differences. "Branding" is really not a good reason.

(Continue reading)

headers

Ilija Kocho | 15 Jan 2012 23:21

Re: Gnutools: consideration for upgrade to GCC 4.6

On 15.01.2012 19:42, Sergei Gavrikov wrote:
> On Sun, 15 Jan 2012, Grant Edwards wrote:
>
>> On 2012-01-14, Sergei Gavrikov<sergei.gavrikov <at> gmail.com>  wrote:
>>
>>> By the way I like their built-in __rtems__ definition for own GCC builds
>>> and I guess in the end we would propagate __ecos__ for own ones on the
>>> occasion of renewal.
>> Why?
> Simply to distinguish the official releases of toolchains (I hope well
> tested) and any home-cooked toolchains. I meant such predefined things
> for GCC (CPP)
>
>    % i386-rtems4.11-gcc -dM -E -</dev/null | grep __rtems__
>    #define __rtems__ 1
>
> and the same we could have for officially supported releases for ecos,
> e.g.
>
>    % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
>    #define __ecos__ 1
>
> Secondly, it lets anyone to use such checks in sources, e.g.
>
>    #if __linux__
>    # include<endian.h>
>    #elif __ecos__
>    # include<machine/endian.h>
>    #else
>    ...

(Continue reading)

headers

Grant Edwards | 16 Jan 2012 16:18

Re: Gnutools: consideration for upgrade to GCC 4.6

On 2012-01-15, Sergei Gavrikov <sergei.gavrikov <at> gmail.com> wrote:
> On Sun, 15 Jan 2012, Grant Edwards wrote:
>
>> On 2012-01-14, Sergei Gavrikov <sergei.gavrikov <at> gmail.com> wrote:
>> 
>> > By the way I like their built-in __rtems__ definition for own GCC builds
>> > and I guess in the end we would propagate __ecos__ for own ones on the
>> > occasion of renewal.
>> 
>> Why?
>
> Simply to distinguish the official releases of toolchains (I hope well
> tested) and any home-cooked toolchains. I meant such predefined things
> for GCC (CPP)

I realize it would distinguish official toolchains from others.  What
I want to know is why that's useful.

>   % i386-rtems4.11-gcc -dM -E - </dev/null | grep __rtems__
>   #define __rtems__ 1
>
> and the same we could have for officially supported releases for ecos,
> e.g.
>
>   % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
>   #define __ecos__ 1
>
> Secondly, it lets anyone to use such checks in sources, e.g.
>
>   #if __linux__

(Continue reading)

headers

Sergei Gavrikov | 16 Jan 2012 21:43

Re: Gnutools: consideration for upgrade to GCC 4.6

On Mon, 16 Jan 2012, Grant Edwards wrote:

> On 2012-01-15, Sergei Gavrikov <sergei.gavrikov <at> gmail.com> wrote:
> > On Sun, 15 Jan 2012, Grant Edwards wrote:
> >
> >> On 2012-01-14, Sergei Gavrikov <sergei.gavrikov <at> gmail.com> wrote:
> >> 
> >> > By the way I like their built-in __rtems__ definition for own GCC
> >> > builds and I guess in the end we would propagate __ecos__ for own
> >> > ones on the occasion of renewal.
> >> 
> >> Why?
> >
> > Simply to distinguish the official releases of toolchains (I hope
> > well tested) and any home-cooked toolchains. I meant such predefined
> > things for GCC (CPP)
> 
> I realize it would distinguish official toolchains from others.  What
> I want to know is why that's useful.
> 
> >   % i386-rtems4.11-gcc -dM -E - </dev/null | grep __rtems__
> >   #define __rtems__ 1
> >
> > and the same we could have for officially supported releases for
> > ecos, e.g.
> >
> >   % i386-ecos3.12-gcc -dM -E -</dev/null | grep __ecos__
> >   #define __ecos__ 1
> >
> > Secondly, it lets anyone to use such checks in sources, e.g.

(Continue reading)

headers

Sergei Gavrikov | 16 Jan 2012 22:11

Re: Gnutools: consideration for upgrade to GCC 4.6

On Mon, 16 Jan 2012, Sergei Gavrikov wrote:

> I hope I have convinced you and Stano that I did not suggest to "close"
> eCos sources by __ecos__ checks. More that to propagate that built-in
> definition is only a few lines for GCC patch and if that is issue I am
> ready to withdraw my "I like their built-in" 

Nobody (me too) said (thought) about:

  http://www.ecoscentric.com/trademark_usage.shtml

AIANL. So, I actually withdraw my "wish" as [eCos] is registered
trademark and anyone would use our patches and abuse the word.

Sergei

headers

Bernard Fouché | 17 Jan 2012 10:57

Re: Gnutools: consideration for upgrade to GCC 4.6

Le 16/01/2012 22:11, Sergei Gavrikov a écrit :
> On Mon, 16 Jan 2012, Sergei Gavrikov wrote:
>
>> I hope I have convinced you and Stano that I did not suggest to "close"
>> eCos sources by __ecos__ checks. More that to propagate that built-in
>> definition is only a few lines for GCC patch and if that is issue I am
>> ready to withdraw my "I like their built-in" 
> Nobody (me too) said (thought) about:
>
>    http://www.ecoscentric.com/trademark_usage.shtml
>
> AIANL. So, I actually withdraw my "wish" as [eCos] is registered
> trademark and anyone would use our patches and abuse the word.
>
> Sergei

Being able to identify/check the toolchain used seems a very good idea. 
Why not ask eCosCentric about the legal issue? They already make a 
toolchain available for public eCos, that can be installed with the 
installation tool (see http://ecos.sourceware.org/getstart.html) . IMHO 
it is in the interest of eCos to avoid having its public image altered 
because of bugs that are related to the toolchain and not eCos itself.

The message from Tomas is a perfect example of such a need:

Le 17/01/2012 10:36, Tomas Frydrych a écrit :
> Some of the more recent gccs were not producing usable binaries on some
> platforms (including arm) with the -Os option. I do not know if this is
> the case with 4.6.2, and I don't think ecos uses -Os by default, but it

(Continue reading)

headers

Paul Beskeen | 17 Jan 2012 11:38

Re: Gnutools: consideration for upgrade to GCC 4.6

On 17/01/2012 09:57, Bernard Fouché wrote:
> Le 16/01/2012 22:11, Sergei Gavrikov a écrit :
>> On Mon, 16 Jan 2012, Sergei Gavrikov wrote:
>>
>>> I hope I have convinced you and Stano that I did not suggest to "close"
>>> eCos sources by __ecos__ checks. More that to propagate that built-in
>>> definition is only a few lines for GCC patch and if that is issue I am
>>> ready to withdraw my "I like their built-in" 
>> Nobody (me too) said (thought) about:
>>
>>    http://www.ecoscentric.com/trademark_usage.shtml
>>
>> AIANL. So, I actually withdraw my "wish" as [eCos] is registered
>> trademark and anyone would use our patches and abuse the word.
>>
>> Sergei
> 
> Being able to identify/check the toolchain used seems a very good idea.
> Why not ask eCosCentric about the legal issue? They already make a
> toolchain available for public eCos, that can be installed with the
> installation tool (see http://ecos.sourceware.org/getstart.html) . IMHO
> it is in the interest of eCos to avoid having its public image altered
> because of bugs that are related to the toolchain and not eCos itself.

On the trademark front there is no issue with the public eCos release
using this as required (see 1.1.1/4 section in the above referenced URL).

On a personal note, I would however avoid the use of __ecos__ in the
toolchain for all the reasons that Grant has already pointed out.
Critically, you don't want to limit users to a specific set of toolchains.

(Continue reading)

headers

Sergei Gavrikov | 17 Jan 2012 13:27

Re: Gnutools: consideration for upgrade to GCC 4.6

All

I changed my mind. I withdraw my request. All should know what (which
toolchain) they use. If I do not trust myself, no one denies to patch
GCC to get own built-in define, e.g. __home_cooked__ as a memory stick
to distinguish toolchains 

Thanks for your points and time!

Sergei

On Tue, 17 Jan 2012, Paul Beskeen wrote:

> On 17/01/2012 09:57, Bernard Fouché wrote:
> > Le 16/01/2012 22:11, Sergei Gavrikov a écrit :
> >> On Mon, 16 Jan 2012, Sergei Gavrikov wrote:
> >>
> >>> I hope I have convinced you and Stano that I did not suggest to
> >>> "close" eCos sources by __ecos__ checks. More that to propagate
> >>> that built-in definition is only a few lines for GCC patch and if
> >>> that is issue I am ready to withdraw my "I like their built-in"
> >>> 
> >> Nobody (me too) said (thought) about:
> >>
> >>    http://www.ecoscentric.com/trademark_usage.shtml
> >>
> >> AIANL. So, I actually withdraw my "wish" as [eCos] is registered
> >> trademark and anyone would use our patches and abuse the word.
> >>
> >> Sergei

(Continue reading)

headers

Ilija Kocho | 14 Jan 2012 17:24

Re: Gnutools: consideration for upgrade to GCC 4.6

On 14.01.2012 11:22, John Dallaway wrote:
> Hi Ilija and all
>
> Ilija Kocho wrote:
>
>> Our GCC 4.3.2 is ageing and perhaps we should consider an upgrade.
>> My motive is it's lacking of support for Cortex-M4 SIMD (aka DSP) and
>> FPU instructions, but I think that other architectures shall gain from
>> newer compiler too. I have made some signal processing tests with GCC
>> 4.6.2 against current eCos compiler and they show performance gain even
>> with Cortex-M3 setting, though moderate. Performance is considerable
>> when Cortex-M4 setting is selected and is tremendous, as expected, when
>> SIMD are used. Recently introduced Cortex-M products with FPU (Kinetis
>> K70, K61, STM32F4) will further emphasise the benefit.
>>
>> Another reason, maybe not so important, is that GCC 4.3 is not
>> officially supported any more.
>>
>> Regarding this, I state my wish that we move to the latest stable GCC
>> release, that is at present rel. 4.6.2, accompanied with respective
>> binutils. I have tested binutils 2.21 but in meantime 2.22 has been
>> released. Of course, the list wouldn't be complete without the latest GDB.
> Moving to a more recent GCC makes sense to me.
>
> There are sure to be some new compiler warnings to deal with in the eCos
> sources. Are you aware of the scale of this issue with eCos CVS and GCC
> 4.6.2?

If it could be some measure, the compilation of eCos library for the 
/default/ template (target K60N512) raises 11 warnings, all seem to be

(Continue reading)

headers

Jonathan Larmour | 23 Jan 2012 02:13

Re: Gnutools: consideration for upgrade to GCC 4.6

On 14/01/12 16:24, Ilija Kocho wrote:
> On 14.01.2012 11:22, John Dallaway wrote:
>> There are sure to be some new compiler warnings to deal with in the eCos
>> sources. Are you aware of the scale of this issue with eCos CVS and GCC
>> 4.6.2?
> 
> If it could be some measure, the compilation of eCos library for the
> /default/ template (target K60N512) raises 11 warnings, all seem to be
> the same type:
> warning: variable ‘<varname>’ set but not used [-Wunused-but-set-variable]
> Some cases are unused variables indeed, but of some the usage is
> "hidden" (within asm() or macro).

Try redboot (on a target including flash and network). There's a lot more
there.

>> There are a few patches that were applied to current toolchain sources:
>>
>>    ftp://ecos.sourceware.org/pub/ecos/gnutools/src/
>>
>> It would be useful to review these and determine which are still
>> relevant.
> 
> I have implemented them in my build (for ARM only). They seem to fit
> with the new code but regarding relevancy it probably requires more
> analysis and better knowledge of GCC intrinsics than mine.

Feel free to ask.

Jifl

(Continue reading)

headers

Ilija Kocho | 23 Jan 2012 19:40

Re: Gnutools: consideration for upgrade to GCC 4.6

On 23.01.2012 02:13, Jonathan Larmour wrote:
> On 14/01/12 16:24, Ilija Kocho wrote:
>> On 14.01.2012 11:22, John Dallaway wrote:
>>> There are sure to be some new compiler warnings to deal with in the eCos
>>> sources. Are you aware of the scale of this issue with eCos CVS and GCC
>>> 4.6.2?
>> If it could be some measure, the compilation of eCos library for the
>> /default/ template (target K60N512) raises 11 warnings, all seem to be
>> the same type:
>> warning: variable ‘<varname>’ set but not used [-Wunused-but-set-variable]
>> Some cases are unused variables indeed, but of some the usage is
>> "hidden" (within asm() or macro).
> Try redboot (on a target including flash and network). There's a lot more
> there.

Thank you for notice jifl, my systems are typically small and I seldom 
use RedBoot.
I'm not surprised as some warnings also appear with GCC 4.3.2. Testing 
period would be an opportunity to get rid of them.

>>> There are a few patches that were applied to current toolchain sources:
>>>
>>>     ftp://ecos.sourceware.org/pub/ecos/gnutools/src/
>>>
>>> It would be useful to review these and determine which are still
>>> relevant.
>> I have implemented them in my build (for ARM only). They seem to fit
>> with the new code but regarding relevancy it probably requires more
>> analysis and better knowledge of GCC intrinsics than mine.
> Feel free to ask.

(Continue reading)

headers

Jonathan Larmour | 23 Jan 2012 20:28

Re: Gnutools: consideration for upgrade to GCC 4.6

On 23/01/12 18:40, Ilija Kocho wrote:
> 
> I suppose that it is related to infamous Cortex-M LDRD bug
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka8542.html
> 
> for which control has been provided in GCC 4.4
> http://gcc.gnu.org/gcc-4.4/changes.html
> I have rejected this patch, but my assumption may be wrong. Please confirm.

You are spot on. That patch is indeed now obsolete for newer tools. It's
funny to think that AFAIK it was in eCos (well, specifically,
nickg <at> ecoscentric) it was first discovered when doing the port.

Jifl

headers

Alex Schuilenburg | 25 Jan 2012 13:29

Re: Gnutools: consideration for upgrade to GCC 4.6

Hi Ilija

eCosCentric are happy to make its eCos test farm available to you for
automated testing of the new toolchains.

Having gone through our list of ARM and Cortex hardware in our test farm
and the hardware supported in the public eCos repository (i.e. the
physical hardware we have and what is supported in the public eCos
repository), we propose running tests for the Embedded Artists
LPC2468-32 (to test ARM7 and thumb mode, as well as the network stacks
with the newer toolchain since this board has ethernet support) and the
ST STM3210E-EVAL evaluation board (to test Cortex-M3).

The tests will take around 2 weeks to run after which I will post the
results for you to examine.  The results will be accessible through a
web interface in three forms:

 1. eCos build results
    eCos and its tests will be built in a number of different eCos
    configurations utilising a number of different compiler options.
    Each configuration is known as a perm (short for permutation).  A
    build is a tuple consisting of target+source+toolchain+perm.  The
    results of each build consist of the shell script used to configure
    and build eCos and the tests (so you can rebuild yourself), the eCos
    ecm export (so you can import the configuration without having to
    run the shell script), as well as the full compilation and link
    output of the build.
 2. eCos test results
    Each test built against a tuple is executed on real hardware with
    the test result logged. If a test fails, the full output is

(Continue reading)

headers

Ilija Kocho | 25 Jan 2012 21:59

Re: Gnutools: consideration for upgrade to GCC 4.6

Hi Alex

I wish to thank eCosCentric for supporting eCos GCC 4.6 release. It will 
both assure quality of this release and strengthen the image of eCos 
community toolchain.

In order to best utilize 2 lab. weeks of testing we should have well 
prepared binaries. In my view, it would be the best to carry out the 
eCosCentric lab. test as final release verification step after some 
field testing. In a course of field testing we shall also prepare eCos 
itself, (eliminate warnings, etc.).

Regarding targets, I don't have objections. However you may find 
interesting Freescale K70 (Cortex-M4F)
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-K70F120M&parentCode=K70&fpsp=1
mainly because of single precision FPU support. Btw hard-float library 
support for Cortex-M4F will be new feature in this GCC release.
I must admit that we don't have BSP yet as this is brand new chip but am 
working on it and expect to have it in short time.

Note: The considerations above are my personal. I would appreciate 
suggestions from other maintainers and developers.

We'll keep you up to date with the progress.

Regards

Ilija

On 25.01.2012 13:29, Alex Schuilenburg wrote:

(Continue reading)

headers

Alex Schuilenburg | 26 Jan 2012 14:35

Re: Gnutools: consideration for upgrade to GCC 4.6

Hi Ilija

On 2012-01-25 20:59, Ilija Kocho wrote:
> Hi Alex
>
> I wish to thank eCosCentric for supporting eCos GCC 4.6 release. It
> will both assure quality of this release and strengthen the image of
> eCos community toolchain.

NP - it is a community effort after all 

> In order to best utilize 2 lab. weeks of testing we should have well
> prepared binaries. In my view, it would be the best to carry out the
> eCosCentric lab. test as final release verification step after some
> field testing. In a course of field testing we shall also prepare eCos
> itself, (eliminate warnings, etc.).

We have the opposite view - our test farm finds errors which normal user
and field testing does not catch.  I think the earlier you get the
toolchain into the test farm the better because you will at least
minimise the user and field regression testing needed when you fix
issues thrown up by the farm.

We are happy to throw as many toolchain candidates as needed into the
test farm, with the only restriction being the bandwidth each board runs
the tests, so don't feel you have to hold back and use the farm for
final verification. Our test farm has thrown up far more eCos bugs and
toolchain issues than the rest of the community has to date.

>

(Continue reading)

headers

Ilija Kocho | 26 Jan 2012 21:17

Re: Gnutools: consideration for upgrade to GCC 4.6

Hi Alex

On 26.01.2012 14:35, Alex Schuilenburg wrote:
> Hi Ilija
>
> On 2012-01-25 20:59, Ilija Kocho wrote:
>> Hi Alex
>>
>> I wish to thank eCosCentric for supporting eCos GCC 4.6 release. It
>> will both assure quality of this release and strengthen the image of
>> eCos community toolchain.
> NP - it is a community effort after all 
>
>
>> In order to best utilize 2 lab. weeks of testing we should have well
>> prepared binaries. In my view, it would be the best to carry out the
>> eCosCentric lab. test as final release verification step after some
>> field testing. In a course of field testing we shall also prepare eCos
>> itself, (eliminate warnings, etc.).
> We have the opposite view - our test farm finds errors which normal user
> and field testing does not catch.  I think the earlier you get the
> toolchain into the test farm the better because you will at least
> minimise the user and field regression testing needed when you fix
> issues thrown up by the farm.
>
> We are happy to throw as many toolchain candidates as needed into the
> test farm, with the only restriction being the bandwidth each board runs
> the tests, so don't feel you have to hold back and use the farm for
> final verification. Our test farm has thrown up far more eCos bugs and
> toolchain issues than the rest of the community has to date.

(Continue reading)

headers

Ilija Kocho | 13 Feb 2012 23:02

eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]

Hi Alex

eCos GNU tools 4.6.2-20120125 (arm_eabi) binaries are ready for testing.
John has placed them on FTP and by now most of the mirrors should have
updated.

I guess this one is closest to you:
http://www.mirrorservice.org/sites/sourceware.org/pub/ecos/gnutools/i386linux/test/ecos-gnutools-arm-eabi-20120125.i386linux.tar.bz2

And here are the patches:
http://www.mirrorservice.org/sites/sourceware.org/pub/ecos/gnutools/src/test/ecos-gnutools-20120125-patches.tar.bz2

The specific feature of public eCos is that it uses uSTL rather than
stdlibc++. Would it be possible for you to add ustl with fileio tests?
Should I be of any help please contact me.

Cheers
Ilija

On 25.01.2012 13:29, Alex Schuilenburg wrote:
> Hi Ilija
>
> eCosCentric are happy to make its eCos test farm available to you for
> automated testing of the new toolchains.
>
> Having gone through our list of ARM and Cortex hardware in our test farm
> and the hardware supported in the public eCos repository (i.e. the
> physical hardware we have and what is supported in the public eCos
> repository), we propose running tests for the Embedded Artists
> LPC2468-32 (to test ARM7 and thumb mode, as well as the network stacks

(Continue reading)

headers

Alex Schuilenburg | 20 Feb 2012 16:59

Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]

Hi Ilija,

On 2012-02-13 22:02, Ilija Kocho wrote:
> Hi Alex
>
> eCos GNU tools 4.6.2-20120125 (arm_eabi) binaries are ready for testing.
> John has placed them on FTP and by now most of the mirrors should have
> updated.
>
> I guess this one is closest to you:
> http://www.mirrorservice.org/sites/sourceware.org/pub/ecos/gnutools/i386linux/test/ecos-gnutools-arm-eabi-20120125.i386linux.tar.bz2
>
> And here are the patches:
> http://www.mirrorservice.org/sites/sourceware.org/pub/ecos/gnutools/src/test/ecos-gnutools-20120125-patches.tar.bz2
>
> The specific feature of public eCos is that it uses uSTL rather than
> stdlibc++. Would it be possible for you to add ustl with fileio tests?
> Should I be of any help please contact me.

Yes - should be no problem.  Just send me a minimal config/export of the
configuration setting you want and I will add that to the perm list.

-- Alex

>
> Cheers
> Ilija
>
>
>

(Continue reading)

headers

Ilija Kocho | 20 Feb 2012 21:45

Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]

On 20.02.2012 16:59, Alex Schuilenburg wrote:
> Hi Ilija,
>
> On 2012-02-13 22:02, Ilija Kocho wrote:
>> Hi Alex
>>
>> eCos GNU tools 4.6.2-20120125 (arm_eabi) binaries are ready for testing.
>> John has placed them on FTP and by now most of the mirrors should have
>> updated.
>>
>> I guess this one is closest to you:
>> http://www.mirrorservice.org/sites/sourceware.org/pub/ecos/gnutools/i386linux/test/ecos-gnutools-arm-eabi-20120125.i386linux.tar.bz2
>>
>> And here are the patches:
>> http://www.mirrorservice.org/sites/sourceware.org/pub/ecos/gnutools/src/test/ecos-gnutools-20120125-patches.tar.bz2
>>
>> The specific feature of public eCos is that it uses uSTL rather than
>> stdlibc++. Would it be possible for you to add ustl with fileio tests?
>> Should I be of any help please contact me.
> Yes - should be no problem.  Just send me a minimal config/export of the
> configuration setting you want and I will add that to the perm list.
>
> -- Alex

Thank you Alex. Please find attached ecm file.

Ilija

(Continue reading)

headers

Alex Schuilenburg | 2 Mar 2012 17:36

Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]

Hi Ilija,

On 2012-02-13 22:02, Ilija Kocho wrote:
> Hi Alex
>
> eCos GNU tools 4.6.2-20120125 (arm_eabi) binaries are ready for testing.
> John has placed them on FTP and by now most of the mirrors should have
> updated.
>
> I guess this one is closest to you:
> http://www.mirrorservice.org/sites/sourceware.org/pub/ecos/gnutools/i386linux/test/ecos-gnutools-arm-eabi-20120125.i386linux.tar.bz2
>
> And here are the patches:
> http://www.mirrorservice.org/sites/sourceware.org/pub/ecos/gnutools/src/test/ecos-gnutools-20120125-patches.tar.bz2

Thanks.  I have taken a test snapshot of anoncvs on 2012-03-01
00:00:00:00 along with the toolchain above and thrown that to our test
farm.  Unfortunately the Embedded Artists LPC2468-32 anoncvs port
appears to be either incompatible with our RedBoot or is broken in
anoncvs.  All the tests fail to hit a breakpoint set at cyg_test_init,
or run without any breakpoints. I suspect this port appears to have
suffered bitrot since the V3 as the board appears to have been run in
our testfarm for the public eCos 3.0 release in 2009, and the RedBoot on
the board is dated Apr 25 2008  which goes back to V2.

I have just switched to using our eCosPro sources and the first couple
of tests I checked passed, so at least this confirms this is not any
issue with the toolchain. Using the same set of eCosPro sources with our
ecospro tools and the anoncvs tools at least will tell us if there is
any regression.  Unfortunately though, if there is a regression we will

(Continue reading)

headers

Ilija Kocho | 3 Mar 2012 14:32

Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]

On 02.03.2012 17:36, Alex Schuilenburg wrote:
> Hi Ilija,
>
> On 2012-02-13 22:02, Ilija Kocho wrote:
>> Hi Alex
>>
>> eCos GNU tools 4.6.2-20120125 (arm_eabi) binaries are ready for testing.
>> John has placed them on FTP and by now most of the mirrors should have
>> updated.
>>
>> I guess this one is closest to you:
>> http://www.mirrorservice.org/sites/sourceware.org/pub/ecos/gnutools/i386linux/test/ecos-gnutools-arm-eabi-20120125.i386linux.tar.bz2
>>
>> And here are the patches:
>> http://www.mirrorservice.org/sites/sourceware.org/pub/ecos/gnutools/src/test/ecos-gnutools-20120125-patches.tar.bz2
> Thanks.  I have taken a test snapshot of anoncvs on 2012-03-01
> 00:00:00:00 along with the toolchain above and thrown that to our test
> farm.  Unfortunately the Embedded Artists LPC2468-32 anoncvs port
> appears to be either incompatible with our RedBoot or is broken in
> anoncvs.  All the tests fail to hit a breakpoint set at cyg_test_init,
> or run without any breakpoints. I suspect this port appears to have
> suffered bitrot since the V3 as the board appears to have been run in
> our testfarm for the public eCos 3.0 release in 2009, and the RedBoot on
> the board is dated Apr 25 2008  which goes back to V2.
>
> I have just switched to using our eCosPro sources and the first couple
> of tests I checked passed, so at least this confirms this is not any
> issue with the toolchain. Using the same set of eCosPro sources with our
> ecospro tools and the anoncvs tools at least will tell us if there is
> any regression.  Unfortunately though, if there is a regression we will

(Continue reading)

headers

Alex Schuilenburg | 4 Mar 2012 01:09

Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]

On 03/03/2012 13:32, Ilija Kocho wrote:
> On 02.03.2012 17:36, Alex Schuilenburg wrote:
>> [...]
>> Thanks.  I have taken a test snapshot of anoncvs on 2012-03-01
>> 00:00:00:00 along with the toolchain above and thrown that to our test
>> farm.  Unfortunately the Embedded Artists LPC2468-32 anoncvs port
>> appears to be either incompatible with our RedBoot or is broken in
>> anoncvs.  All the tests fail to hit a breakpoint set at cyg_test_init,
>> or run without any breakpoints. I suspect this port appears to have
>> suffered bitrot since the V3 as the board appears to have been run in
>> our testfarm for the public eCos 3.0 release in 2009, and the RedBoot on
>> the board is dated Apr 25 2008  which goes back to V2.
>>
>> I have just switched to using our eCosPro sources and the first couple
>> of tests I checked passed, so at least this confirms this is not any
>> issue with the toolchain. Using the same set of eCosPro sources with our
>> ecospro tools and the anoncvs tools at least will tell us if there is
>> any regression.  Unfortunately though, if there is a regression we will
>> only be able to report the test/s that failed along with the flags and
>> configuration used to build the tests.  Otherwise somebody is going to
>> need to fix the anoncvs port for the Embedded Artists LPC2468-32 board.
> Thank you Alex.
> I think that the first step is to find out whether it is a problem with
> EA LPC2468-32 code or more general. Unfortunately I am not able to test
> with this board as we don't have one

I am pretty certain it is an issue with the EA LPC2468-32 code in
anoncvs as the eCosPro EA LPC2468-32 builds and runs fine, although it
could be a more general issues with the anoncvs code (see below).

(Continue reading)

headers

Sergei Gavrikov | 4 Mar 2012 18:49

Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]

On Sun, 4 Mar 2012, Alex Schuilenburg wrote:

> On 03/03/2012 13:32, Ilija Kocho wrote:
> > On 02.03.2012 17:36, Alex Schuilenburg wrote:
> >> [...]
> >> Thanks.  I have taken a test snapshot of anoncvs on 2012-03-01
> >> 00:00:00:00 along with the toolchain above and thrown that to our test
> >> farm.  Unfortunately the Embedded Artists LPC2468-32 anoncvs port
> >> appears to be either incompatible with our RedBoot or is broken in
> >> anoncvs.  All the tests fail to hit a breakpoint set at cyg_test_init,
> >> or run without any breakpoints. I suspect this port appears to have
> >> suffered bitrot since the V3 as the board appears to have been run in
> >> our testfarm for the public eCos 3.0 release in 2009, and the RedBoot on
> >> the board is dated Apr 25 2008  which goes back to V2.
> >>
> >> I have just switched to using our eCosPro sources and the first couple
> >> of tests I checked passed, so at least this confirms this is not any
> >> issue with the toolchain. Using the same set of eCosPro sources with our
> >> ecospro tools and the anoncvs tools at least will tell us if there is
> >> any regression.  Unfortunately though, if there is a regression we will
> >> only be able to report the test/s that failed along with the flags and
> >> configuration used to build the tests.  Otherwise somebody is going to
> >> need to fix the anoncvs port for the Embedded Artists LPC2468-32 board.
> > Thank you Alex.
> > I think that the first step is to find out whether it is a problem with
> > EA LPC2468-32 code or more general. Unfortunately I am not able to test
> > with this board as we don't have one
> 
> I am pretty certain it is an issue with the EA LPC2468-32 code in
> anoncvs as the eCosPro EA LPC2468-32 builds and runs fine, although it

(Continue reading)

headers

Alex Schuilenburg | 5 Mar 2012 00:08

Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]

On 04/03/2012 17:49, Sergei Gavrikov wrote:
> [...]
>  
> Hi Alex
>
> I just wonder, is there
>
>   set cyg_test_is_simulator=0
>
> line in your gdbinit file?
We don't use gdbint.  Our testfarm uses a mixture of perl and expect to
drive the tests, mainly so we can add additional automatic diagnostic
code when something goes wrong.

Anyway, as I mentioned, the tests do not even hit the initial
cyg_test_init breakpoint so they do not get to that stage.

> [...]
>
>
> GDB 7.3.1
>
> (gdb) set cyg_test_is_simulator=0
> No symbol "cyg_test_is_simulator" in current context.
>
> IMHO, this claim is okay, adn GDB 7.3.1 does not process the next lines in
> gdbinit.
It is OK.  Not as bad as some versions of gdb which interpreted no
symbol as NULL and so would write 0 to NULL.  They always gave
interesting results, but the gdb code segment below worked around this:

(Continue reading)

headers

John Dallaway | 4 Mar 2012 20:37

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi Alex

Alex Schuilenburg wrote:

> On 03/03/2012 13:32, Ilija Kocho wrote:
>> On 02.03.2012 17:36, Alex Schuilenburg wrote:
>>> [...]
>>> Thanks.  I have taken a test snapshot of anoncvs on 2012-03-01
>>> 00:00:00:00 along with the toolchain above and thrown that to our test
>>> farm.  Unfortunately the Embedded Artists LPC2468-32 anoncvs port
>>> appears to be either incompatible with our RedBoot or is broken in
>>> anoncvs.  All the tests fail to hit a breakpoint set at cyg_test_init,
>>> or run without any breakpoints. I suspect this port appears to have
>>> suffered bitrot since the V3 as the board appears to have been run in
>>> our testfarm for the public eCos 3.0 release in 2009, and the RedBoot on
>>> the board is dated Apr 25 2008  which goes back to V2.
>>>
>>> I have just switched to using our eCosPro sources and the first couple
>>> of tests I checked passed, so at least this confirms this is not any
>>> issue with the toolchain. Using the same set of eCosPro sources with our
>>> ecospro tools and the anoncvs tools at least will tell us if there is
>>> any regression.  Unfortunately though, if there is a regression we will
>>> only be able to report the test/s that failed along with the flags and
>>> configuration used to build the tests.  Otherwise somebody is going to
>>> need to fix the anoncvs port for the Embedded Artists LPC2468-32 board.
>> 
>> Thank you Alex.
>> I think that the first step is to find out whether it is a problem with
>> EA LPC2468-32 code or more general. Unfortunately I am not able to test
>> with this board as we don't have one

(Continue reading)

headers

Alex Schuilenburg | 5 Mar 2012 00:47

Re: eCos GNU tools 4.6.2-20120125 ready for testing

On 04/03/2012 19:37, John Dallaway wrote:
> Hi Alex
>
> Alex Schuilenburg wrote:
>
>> On 03/03/2012 13:32, Ilija Kocho wrote:
>>> On 02.03.2012 17:36, Alex Schuilenburg wrote:
>>>> [...]
>>>> Thanks.  I have taken a test snapshot of anoncvs on 2012-03-01
>>>> 00:00:00:00 along with the toolchain above and thrown that to our test
>>>> farm.  Unfortunately the Embedded Artists LPC2468-32 anoncvs port
>>>> appears to be either incompatible with our RedBoot or is broken in
>>>> anoncvs.  All the tests fail to hit a breakpoint set at cyg_test_init,
>>>> or run without any breakpoints. I suspect this port appears to have
>>>> suffered bitrot since the V3 as the board appears to have been run in
>>>> our testfarm for the public eCos 3.0 release in 2009, and the RedBoot on
>>>> the board is dated Apr 25 2008  which goes back to V2.
>>>>
>>>> I have just switched to using our eCosPro sources and the first couple
>>>> of tests I checked passed, so at least this confirms this is not any
>>>> issue with the toolchain. Using the same set of eCosPro sources with our
>>>> ecospro tools and the anoncvs tools at least will tell us if there is
>>>> any regression.  Unfortunately though, if there is a regression we will
>>>> only be able to report the test/s that failed along with the flags and
>>>> configuration used to build the tests.  Otherwise somebody is going to
>>>> need to fix the anoncvs port for the Embedded Artists LPC2468-32 board.
>>> Thank you Alex.
>>> I think that the first step is to find out whether it is a problem with
>>> EA LPC2468-32 code or more general. Unfortunately I am not able to test
>>> with this board as we don't have one

(Continue reading)

headers

Sergei Gavrikov | 5 Mar 2012 08:59

Re: eCos GNU tools 4.6.2-20120125 ready for testing

On Sun, 4 Mar 2012, Alex Schuilenburg wrote:

> On 04/03/2012 19:37, John Dallaway wrote:
> > Hi Alex
> >
> > Alex Schuilenburg wrote:

[snip]

> >> There is only one issue uncovered so far, and that is the backtrace
> >> of gdb 7.3 is unreliable.  It occasionally can end up in an
> >> infinite loop, while our own 7.2 gdb for eCosPro works just fine in
> >> exactly the same tests (i.e. built with gcc 4.6.2).  However, I
> >> guess users could add a "set backtracelimit=100" and that should
> >> catch this issue.
> > That is useful info, thank you. Could you provide examples of the
> > infinite backtrace please? We need to understand which of the
> > backtrace backstops is missing or ineffective.
> 
> kexcept1 and except1 backtrace fail in every perm with 7.3 gdb.

I confirm it (I got the same for ARM7 target), it seems to me this is
old story http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000699

But, if GDB 7.2 (I hope it was not patched a lot  manages that
properly, I would stick on GDB 7.2 (I will test it).

Thank you for your information!

Sergei

(Continue reading)

headers

Sergei Gavrikov | 7 Mar 2012 14:50

Re: eCos GNU tools 4.6.2-20120125 ready for testing

On Mon, 5 Mar 2012, Sergei Gavrikov wrote:
> On Sun, 4 Mar 2012, Alex Schuilenburg wrote:
> > On 04/03/2012 19:37, John Dallaway wrote:
> > > Hi Alex
> > >
> > > Alex Schuilenburg wrote:
> 
> [snip]
> 
> > >> There is only one issue uncovered so far, and that is the
> > >> backtrace of gdb 7.3 is unreliable.  It occasionally can end up
> > >> in an infinite loop, while our own 7.2 gdb for eCosPro works just
> > >> fine in exactly the same tests (i.e. built with gcc 4.6.2).
> > >> However, I guess users could add a "set backtracelimit=100" and
> > >> that should catch this issue.
> > > That is useful info, thank you. Could you provide examples of the
> > > infinite backtrace please? We need to understand which of the
> > > backtrace backstops is missing or ineffective.
> > 
> > kexcept1 and except1 backtrace fail in every perm with 7.3 gdb.
> 
> I confirm it (I got the same for ARM7 target), it seems to me this is
> old story http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000699
> 
> But, if GDB 7.2 (I hope it was not patched a lot  manages that
> properly, I would stick on GDB 7.2 (I will test it).

I could not manage `bt' issue with GDB 7.2(a), it seems you have more
clever fixes for arm-tdep.{c,h} for 7.2 than there are ones in GDB 7.3
main-stream source.  So, I came back to GDB 7.3.1.

(Continue reading)

headers

Alex Schuilenburg | 7 Mar 2012 12:58

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi Ilija,

The RedBoot issue on the STM3210E-EVAL turned out to be a non-issue. 
eCos and eCosPro RedBoot are compatible. There was an eCosPro specific
issue which I had forgotten about - sorry.  The board ran overnight just
over 1000 tests in different eCos configurations.  There are currently 9
failures, listed according to their configuration name in our test farm.
As jld knows, when a test fails in the farm it is automatically rerun an
additional 2 times to confirm the failure is reproducible.  All other
tests in these configurations passed.

ustl1: bvt05, bvt13, bvt17, sprintf2

infra1: except1, kexcept1, testintr

absent1, compile1: testintr

The eCos used was the version was dated 1 March and the configurations
script segment to create each configuration is listed below.  If you
need any more info, just let me know. I unfortunately don't have the
time at the moment to export the full set of results, but hopefully this
will be enough for you to reproduce the failures.  As a comparison, all
tests passed in eCosPro for the STM3210E-EVAL with the obvious exception
of the ustl1 configuration.

ustl1:

ecosconfig -i new stm3210e_eval
cat > ustl1.ecm <<EOF;
cdl_configuration eCos {

(Continue reading)

headers

Ilija Kocho | 7 Mar 2012 14:00

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Thank you Alex

We will need some time to analyze the results and try to reproduce.
At present I could ony partially comment on ustl tests.

bvt13 and bvt17 require certain input from the user, something which the test machine might not be able to provide.
Similar report from Sergei (pse see NOTE near end of his mail). http://ecos.sourceware.org/ml/ecos-devel/2012-03/msg00001.html
I have tried both tests manually (on TWR-K60N512 target) and they passed.

bvt05 seem's to need a lot of RAM. It was beyond capacity of my target
(128KiB RAM), and maybe even too much for STM3210-EVAL. I'll see if the
test could be changed to run with less memory.

For sprintf2 I don't have explanation - I'll try to rerun on STM3210-EVAL.

I notice that other tests have failed with /uitron/ template with which
I have no experience so I can't comment at present.

Regards
Ilija

On 07.03.2012 12:58, Alex Schuilenburg wrote:
> Hi Ilija,
>
> The RedBoot issue on the STM3210E-EVAL turned out to be a non-issue. 
> eCos and eCosPro RedBoot are compatible. There was an eCosPro specific
> issue which I had forgotten about - sorry.  The board ran overnight just
> over 1000 tests in different eCos configurations.  There are currently 9
> failures, listed according to their configuration name in our test farm.
> As jld knows, when a test fails in the farm it is automatically rerun an

(Continue reading)

headers

Sergei Gavrikov | 7 Mar 2012 14:39

Re: eCos GNU tools 4.6.2-20120125 ready for testing

On Wed, 7 Mar 2012, Ilija Kocho wrote:

> Thank you Alex

Also from me (you have great test farm 

> We will need some time to analyze the results and try to reproduce.
> At present I could ony partially comment on ustl tests.
> 
> bvt13 and bvt17 require certain input from the user, something which the test machine might not be able to provide.
> Similar report from Sergei (pse see NOTE near end of his mail). http://ecos.sourceware.org/ml/ecos-devel/2012-03/msg00001.html
> I have tried both tests manually (on TWR-K60N512 target) and they passed.
> 
> bvt05 seem's to need a lot of RAM. It was beyond capacity of my target
> (128KiB RAM), and maybe even too much for STM3210-EVAL. I'll see if the
> test could be changed to run with less memory.

The `bvt05' is suitable for targets with of amount of RAM even more than
1M. So, I rejected this test from my runs (but when I decreased a number
of items for the 64-bit tests the test passed on ARM7 target).

> For sprintf2 I don't have explanation - I'll try to rerun on STM3210-EVAL.

I found this bug during tests on ARM7 and submit a patch

 http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001490
 http://bugs.ecos.sourceware.org/attachment.cgi?id=1587

As the patch tweaks libc (vsnprintf()) I did not risk commit it without
further discussion.

(Continue reading)

headers

John Dallaway | 7 Mar 2012 14:12

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi Alex

Alex Schuilenburg wrote:

> The RedBoot issue on the STM3210E-EVAL turned out to be a non-issue. 
> eCos and eCosPro RedBoot are compatible. There was an eCosPro specific
> issue which I had forgotten about - sorry.  The board ran overnight just
> over 1000 tests in different eCos configurations.  There are currently 9
> failures, listed according to their configuration name in our test farm.
> As jld knows, when a test fails in the farm it is automatically rerun an
> additional 2 times to confirm the failure is reproducible.  All other
> tests in these configurations passed.

Thank you for the info. I assume this was using your own build of GDB.
Could you switch to arm-eabi-gdb 7.3.1 from the test release for any
future perms please? With Cortex-M target such as STM3210E-EVAL you will
need to specify the attached target description file before connecting
to the target:

  (gdb) set tdesc filename gdb-tdesc-cortexm-fpa.xml

I can confirm that this is working for me.

Thanks, again...

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

Attachment (gdb-tdesc-cortexm-fpa-120307.tar.bz2): application/x-bzip, 1599 bytes

(Continue reading)

headers

Alex Schuilenburg | 12 Mar 2012 17:42

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi John,

On 2012-03-07 13:12, John Dallaway wrote:
> Hi Alex
>
> Alex Schuilenburg wrote:
>
>> The RedBoot issue on the STM3210E-EVAL turned out to be a non-issue. 
>> eCos and eCosPro RedBoot are compatible. There was an eCosPro specific
>> issue which I had forgotten about - sorry.  The board ran overnight just
>> over 1000 tests in different eCos configurations.  There are currently 9
>> failures, listed according to their configuration name in our test farm.
>> As jld knows, when a test fails in the farm it is automatically rerun an
>> additional 2 times to confirm the failure is reproducible.  All other
>> tests in these configurations passed.
> Thank you for the info. I assume this was using your own build of GDB.
> Could you switch to arm-eabi-gdb 7.3.1 from the test release for any
> future perms please? With Cortex-M target such as STM3210E-EVAL you will
> need to specify the attached target description file before connecting
> to the target:
>
>   (gdb) set tdesc filename gdb-tdesc-cortexm-fpa.xml
>
> I can confirm that this is working for me.

Given this comment in
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468#c30 I assume at
some point a newer toolchain will be provided which has a gdb with the
'g' packet length resolved?

(Continue reading)

headers

Alex Schuilenburg | 16 Mar 2012 16:04

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Just a quick update on the stm3210e_eval platform in our test farm,
still with the old toolchain though.  At least this is a marker for the
newer toolchain for this platform.  It finished the complete set of
15584 tests in the small hours of this morning, taking just over 10.5
days to run. Thats slow serial download for you.  There were 116
failures, most were the same tests in different configurations - all
tests passed in the default though.

There were no new tests that failed, the complete list being:

  test              | perm     
 -------------------+---------- 
  bvt05             | ustl1
  bvt13             | ustl1
  bvt17             | ustl1
  cxxsupp           | libc10
  dns1              | bsdnet5
  except1           | bsdnet11, bsdnet2, bsdnet3, bsdnet6, combo12, 
                      combo13, combo15, combo16, combo19, combo21, 
                      combo24, combo3, combo4, combo7, combo9, compile6,
                      infra1, infra2, infra4, kernel13, libc10, libc4,
                      libc9, posix1, posix2, posix3, posix4, posix5,
                      posix6
  kexcept1          | bsdnet11, bsdnet2, bsdnet3, bsdnet6, combo12, 
                      combo13, combo15, combo16, combo19, combo21,
                      combo24, combo3, combo4, combo7, combo9, compile6,
                      infra1, infra2, infra4, kernel13, libc10, libc4,
                      libc9, posix1, posix2, posix3, posix4, posix5,
                      posix6
  signal1 - signals | libc10

(Continue reading)

headers

Alex Schuilenburg | 8 Mar 2012 18:28

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi

Just an updated on the status of the Embedded Artists LPC2468-32 board
in anoncvs.

I have finally got a limping version of RedBoot generated from anoncvs
running on this platform in our test farm, and it does run tests
generated from anoncvs ecos.  Unfortunately both ethernet and flash
support for this board appears broken, so lwip and bsd testing is out. 
When built with flash and/or ethernet support, RedBoot either hangs on
startup (if flash support is included) or fails to recognise the
ethernet device.

So the version of RedBoot I finally installed had broken ethernet and no
flash support, but appears to work OK (it has run 4 anoncvs tests in the
farm since I re-released it an hour ago, 3 passed and the other,
realloc, failed but is also fails in eCosPro so no need to investigate
that. I ran tm_basic by hand yesterday built from the default
configuration and that also passed).

The differences between the eCos and eCosPro BSPs for the Embedded
Artists LPC2468-32 board were too different for the tests and RedBoot
from different source bases to be compatible.  However, before I
switched back to anoncvs RedBoot, the test results from eCosPro only
were good.  The board had run just over 5500 tests and there were no
regressions with the tests I could find between our GNU tools and eCos
GNU tools 4.6.2-20120125 (apart from the additional warnings during the
builds already reported on this list).  No bsd configurations were built
before I switched.

(Continue reading)

headers

Ilija Kocho | 9 Mar 2012 10:39

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi Alex

Thank you for the update.

Regarding EA target (ARM7TDMI) I'm interested whether the perms include
thumb code. There's an issue reported by Sergei that would be good to
investigate.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468#c25

Ilija

On 08.03.2012 18:28, Alex Schuilenburg wrote:
> Hi
>
> Just an updated on the status of the Embedded Artists LPC2468-32 board
> in anoncvs.
>
> I have finally got a limping version of RedBoot generated from anoncvs
> running on this platform in our test farm, and it does run tests
> generated from anoncvs ecos.  Unfortunately both ethernet and flash
> support for this board appears broken, so lwip and bsd testing is out. 
> When built with flash and/or ethernet support, RedBoot either hangs on
> startup (if flash support is included) or fails to recognise the
> ethernet device.
>
> So the version of RedBoot I finally installed had broken ethernet and no
> flash support, but appears to work OK (it has run 4 anoncvs tests in the
> farm since I re-released it an hour ago, 3 passed and the other,
> realloc, failed but is also fails in eCosPro so no need to investigate
> that. I ran tm_basic by hand yesterday built from the default

(Continue reading)

headers

Alex Schuilenburg | 9 Mar 2012 18:15

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi Ilija,

On 2012-03-09 09:39, Ilija Kocho wrote:
> Hi Alex
>
> Thank you for the update.
>
> Regarding EA target (ARM7TDMI) I'm interested whether the perms include
> thumb code. There's an issue reported by Sergei that would be good to
> investigate.
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468#c25

Yes, the perms include thumb code.  Every perm is built with and without
thumb support, so there are two versions of each test.

Thumb support looks broken as the same test passes in 32 bit mode.  The
complete list of 325 tests run so far is:

+--------------------------------------+---------+-------------------+------------------+------+
| build                                | perm    | test              | result           | time |
+--------------------------------------+---------+-------------------+------------------+------+
| ecos-anoncvs-arm-ea_lpc2468_32       | default | abs               | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | abs               | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | acos              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | acos              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | asctime           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | asctime           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | asin              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | asin              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | atan              | Pass             |    2 |

(Continue reading)

headers

John Dallaway | 10 Mar 2012 18:16

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi Alex

Alex Schuilenburg wrote:

> I have finally got a limping version of RedBoot generated from anoncvs
> running on this platform in our test farm, and it does run tests
> generated from anoncvs ecos.  Unfortunately both ethernet and flash
> support for this board appears broken, so lwip and bsd testing is out. 

Just to be sure, did you set
CYGHWR_HAL_ARM_LPC24XX_EA2468_DATA_BUS_WIDTH == 32 in both the RedBoot
and eCos test application builds for use with your Embedded Artists
LPC2468-32 OEM board?

Very little has changed in the HAL and driver packages for the ea2468
target since the port was first contributed, although the LPC2xxx
ethernet driver has been extended for use with LPC17xx parts.

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

headers

Alex Schuilenburg | 12 Mar 2012 17:11

Re: eCos GNU tools 4.6.2-20120125 ready for testing

John,

On 2012-03-10 17:16, John Dallaway wrote:
> Hi Alex
>
> Alex Schuilenburg wrote:
>
>> I have finally got a limping version of RedBoot generated from anoncvs
>> running on this platform in our test farm, and it does run tests
>> generated from anoncvs ecos.  Unfortunately both ethernet and flash
>> support for this board appears broken, so lwip and bsd testing is out. 
> Just to be sure, did you set
> CYGHWR_HAL_ARM_LPC24XX_EA2468_DATA_BUS_WIDTH == 32 in both the RedBoot
> and eCos test application builds for use with your Embedded Artists
> LPC2468-32 OEM board?

Yes and both anoncvs builds (32 bit and thumb) have

echo cdl_option CYGHWR_HAL_ARM_LPC24XX_EA2468_DATA_BUS_WIDTH { user_value 32 } | ecosconfig import /dev/stdin

as part of their build script.  Don't be misled by the target name
ea_lpc2468_32 as I just added this as an alias to ecos.db for the board
so it would be easier to simply add into the farm without having to
create a new platform and board.

> Very little has changed in the HAL and driver packages for the ea2468
> target since the port was first contributed, although the LPC2xxx
> ethernet driver has been extended for use with LPC17xx parts.

On a hunch following the above remarks I rebuilt RedBoot without

(Continue reading)

headers

Alex Schuilenburg | 13 Mar 2012 14:30

Re: eCos GNU tools 4.6.2-20120125 ready for testing

On 2012-03-12 16:11, Alex Schuilenburg wrote:
> [...]
>> Very little has changed in the HAL and driver packages for the ea2468
>> target since the port was first contributed, although the LPC2xxx
>> ethernet driver has been extended for use with LPC17xx parts.
> On a hunch following the above remarks I rebuilt RedBoot without
> ethernet support.  The same "heaptest" test that failed in the farm
> passes on this newer RedBoot on a second board I have in the office.

Just a quick update.  The same test now passes with the updated RedBoot
(i.e. without ethernet support built in) so it appears that enabling the
ethernet support in RedBoot makes some of the RAM-based eCos test
executables fail. The second board will now be returned to the farm,
with updated non-ethernet RedBoot, to help speed up tests.

Is it worthwhile continuing testing 4.6.2 given
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468 ?

-- Alex

Managing Director/CEO                                eCosCentric Limited

  **  Visit us at the ESC Expo at Design West in San Jose  **
  **  27-29 March, McEnery Convention Center - Stand #846  *

headers

Ilija Kocho | 13 Mar 2012 15:15

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi Alex

Thank you for the update.

On 13.03.2012 14:30, Alex Schuilenburg wrote:

[snip]
>
> Is it worthwhile continuing testing 4.6.2 given
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468 ?

It would be good for us to decide what to do ASAP at latest till end of
this week.

I am testing 4.6.3 on hardware FPU - Cortex-M4F and that bug seems fixed.

I would  also like to check this one reported by Sergei
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468#c25 only I don't
have ARM7TDMI handy. It would be nice if somebody can do this test: Try
4.6.3 on cases that with 4.6.2 pass ARM but fail Thumb?
Ref: http://sourceware.org/ml/ecos-devel/2012-03/msg00024.html

In meantime, Alex, I think you can suspend testing with 4.6.2, but
please keep the results.

Thank you again

Ilija

(Continue reading)

headers

Sergei Gavrikov | 13 Mar 2012 18:46

Re: eCos GNU tools 4.6.2-20120125 ready for testing

On Tue, 13 Mar 2012, Ilija Kocho wrote:

> Hi Alex
> 
> Thank you for the update.
> 
> On 13.03.2012 14:30, Alex Schuilenburg wrote:
> 
> [snip]
> >
> > Is it worthwhile continuing testing 4.6.2 given
> > http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468 ?
> 
> It would be good for us to decide what to do ASAP at latest till end of
> this week.
> 
> I am testing 4.6.3 on hardware FPU - Cortex-M4F and that bug seems fixed.
> 
> I would  also like to check this one reported by Sergei
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001468#c25 only I don't
> have ARM7TDMI handy. It would be nice if somebody can do this test: Try
> 4.6.3 on cases that with 4.6.2 pass ARM but fail Thumb?

That talk was about (this bug was fixed in 4.6.3)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49641

I was able to reproduce #49641 in 4.6.2 with

  cdl_option CYGHWR_THUMB {
      user_value 1

(Continue reading)

headers

John Dallaway | 15 Mar 2012 09:50

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi Sergei

Sergei Gavrikov wrote:

> I tried to build and run "thumb" tests for NXP ARM7TDMI (LPC2294) using
> corresponding RedBoot/GDB
> 
>   ecos-v3_0-branchpoint GCC 4.3.2  most of tests failed
>   ecos AnonCVS          GCC 4.3.2  most of tests failed
>   ecos AnonCVS          GCC 4.6.2  most of tests failed
>   ecos AnonCVS          GCC 4.6.3  most of tests failed
>  
> Thus, it looks like that GCC 4.6.2 is not point of those fails.
> 
> BTW, I never tried ro run "thumb" blobs before on my target and maybe
> I should turn on/off more CDL options than just to force CYGHWR_THUMB
> option.

Enabling CYGHWR_THUMB should be sufficient. Be sure to "make clean" when
switching to Thumb. Also, check that the -mthumb and -mthumb-interwork
flags are definitely present during the building of your eCos tests.

> So, I agree with the said "Thumb support looks broken" at the least for
> lpc2xxx, lpc24xx variants, but, it seems to me it was broken even before
> eCos 3.0.

I have just verified that the kernel tm_basic test builds for target
eb40a (ARM7) with RAM startup and CYGHWR_THUMB. The resulting binary
runs under debug (via RedBoot) without problem. This is using the new
eCos 4.6.2-20120125 test release toolchain.

(Continue reading)

headers

Sergei Gavrikov | 17 Mar 2012 15:50

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi John

John Dallaway wrote:

> Hi Sergei
> 
> Sergei Gavrikov wrote:
> 
> > I tried to build and run "thumb" tests for NXP ARM7TDMI (LPC2294) using
> > corresponding RedBoot/GDB
> > 
> >   ecos-v3_0-branchpoint GCC 4.3.2  most of tests failed
> >   ecos AnonCVS          GCC 4.3.2  most of tests failed
> >   ecos AnonCVS          GCC 4.6.2  most of tests failed
> >   ecos AnonCVS          GCC 4.6.3  most of tests failed
> >  
> > Thus, it looks like that GCC 4.6.2 is not point of those fails.
> > 
> > BTW, I never tried ro run "thumb" blobs before on my target and maybe
> > I should turn on/off more CDL options than just to force CYGHWR_THUMB
> > option.
> 
> Enabling CYGHWR_THUMB should be sufficient. Be sure to "make clean" when
> switching to Thumb. Also, check that the -mthumb and -mthumb-interwork
> flags are definitely present during the building of your eCos tests.

Thank you for this information. Thus, I confirm that I had got the right
thumb binaries for testing.

> > So, I agree with the said "Thumb support looks broken" at the least

(Continue reading)

headers

John Dallaway | 17 Mar 2012 21:57

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi Sergei

On 17 Mar 2012, at 14:50, Sergei Gavrikov <sergei.gavrikov <at> gmail.com> wrote:.

> 
>>> So, I agree with the said "Thumb support looks broken" at the least
>>> for lpc2xxx, lpc24xx variants, but, it seems to me it was broken
>>> even before eCos 3.0.
>> 
>> I have just verified that the kernel tm_basic test builds for target
>> eb40a (ARM7) with RAM startup and CYGHWR_THUMB. The resulting binary
>> runs under debug (via RedBoot) without problem. This is using the new
>> eCos 4.6.2-20120125 test release toolchain.
> 
> What is about GCC optimization in your test? So far, I found that I can
> run only not optimized thumb executables in GDB under RedBoot, and -O1,
> and -O2 builds are failed as I reported above. Though, I guess that you
> use default -O2 optimization for your test.

FYI, I disabled optimisation in the eCos build for my test on eb40a target.

John Dallaway

headers

Stanislav Meduna | 17 Mar 2012 17:43

Re: eCos GNU tools 4.6.2-20120125 ready for testing

On 15.03.2012 09:50, John Dallaway wrote:

>> I tried to build and run "thumb" tests for NXP ARM7TDMI (LPC2294) using
>> corresponding RedBoot/GDB
>>
>>   ecos-v3_0-branchpoint GCC 4.3.2  most of tests failed
>>   ecos AnonCVS          GCC 4.3.2  most of tests failed
>>   ecos AnonCVS          GCC 4.6.2  most of tests failed
>>   ecos AnonCVS          GCC 4.6.3  most of tests failed
>>  
>> Thus, it looks like that GCC 4.6.2 is not point of those fails.

FWIW, I am using a self-compiled gcc 4.5.2 / binutils 2.21.51.0.5
(AFAIR with apatch in as for one regression) with a Cortex-M3
(thumb-2 only) TI Stellaris processor without any problems.
So if there is any general problem regarding thumb, it either
does not affect thumb-2, or is platform specific, or is
a regression in 4.6.x.

> Enabling CYGHWR_THUMB should be sufficient. Be sure to "make clean" when
> switching to Thumb. Also, check that the -mthumb and -mthumb-interwork
> flags are definitely present during the building of your eCos tests.

Out of curiosity, why thumb-interwork? As long as everything
is compiled with -mthumb, according to gcc docs it is actually
contraproductive, isn't it? Maybe this is also the factor.

> There could be a Thumb-related issue within a certain variant/platform
> HAL or device driver package.

(Continue reading)

headers

Ilija Kocho | 18 Mar 2012 20:09

eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing]

Hi Alex

Thank you for testing 4.6.2-20120125.

4.6.3-20120315 is our new test release until we upgrade GDB with Jifl's
patch:
http://ecos.sourceware.org/ml/ecos-discuss/2012-03/msg00064.html

Ilija

headers

Lambrecht Jürgen | 4 Apr 2012 14:57

Re: eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing]

On 03/18/2012 08:09 PM, Ilija Kocho wrote:
>
> Hi Alex
>
> Thank you for testing 4.6.2-20120125.
>
> 4.6.3-20120315 is our new test release until we upgrade GDB with Jifl's
> patch:
> http://ecos.sourceware.org/ml/ecos-discuss/2012-03/msg00064.html
>
> Ilija
>
>
Hi all,

I finished building our "Passenger Information System" application with 
gcc 4.6.3 (started with 4.6.2, noticed no difference when switching to 
4.6.3).
Before, we used gcc 3.2.1.

I first built ecos v3.0 without any problem.
Then I built our application, and it took me many days to solve all new 
warnings (we compile with -Werror):
- unused-but-set-variable -> gave me problems with MISRA rule /16.10/ 
(If a function returns error information, then that error information 
shall be tested.) Our PC-lint checker forces any return argument to be 
used, so I had to add __attribute__ ((unused)).
Also, this warning is annoying for HW drivers: then you sometimes need 
to read some bit just to trigger some behavior, but you are not 
interested in the return value..

(Continue reading)

headers

Ilija Kocho | 4 Apr 2012 15:18

Re: eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing]

Hi Lambrecht

Many thanks for your report. This is AFAIK first report for ARM9.

There are warnings indeed. Many have been fixed in current CVS. Can you
please report warnings (and possibly propose) fixes in Bugzilla?

Thanks again
Ilija

On 04.04.2012 14:57, Lambrecht Jürgen wrote:
> On 03/18/2012 08:09 PM, Ilija Kocho wrote:
>> Hi Alex
>>
>> Thank you for testing 4.6.2-20120125.
>>
>> 4.6.3-20120315 is our new test release until we upgrade GDB with Jifl's
>> patch:
>> http://ecos.sourceware.org/ml/ecos-discuss/2012-03/msg00064.html
>>
>> Ilija
>>
>>
> Hi all,
>
> I finished building our "Passenger Information System" application with 
> gcc 4.6.3 (started with 4.6.2, noticed no difference when switching to 
> 4.6.3).
> Before, we used gcc 3.2.1.
>

(Continue reading)

headers

Bernard Fouché | 31 May 2012 10:37

eCos GNU tools 4.6.3-20120315 and link time optimization

Hi,

I did some testing of 4.6.3 on my Cortex-M3 LPC1765 based app, using the 
eCos CVS repo code.

I use -Os and my goal is to reduce the code size:

4.3.2: 153172 bytes
4.6.3: 144556 bytes
4.6.3, app only compiled with -flto: 136404 bytes

The improvement is significant and the app still works 

However I wasn't able to link with eCos compiled with -flto and 
-Wl,--allow-multiple-definition, the linker fails with:
target.a: could not read symbols: Bad value

I could link adding '-fno-use-linker-plugin' but then I'm back to 144028 
bytes!

Did anyone succeeded in compiling/linking an application and eCos with 
-flto??

Thanks,

      Bernard

headers

Tomas Frydrych | 5 Mar 2012 09:30

Re: eCos GNU tools 4.6.2-20120125 ready for testing

On 04/03/12 19:37, John Dallaway wrote:
> However, this success was achieved using arm-eabi-gdb 6.8.50.20080706.
> There does appear to be an issue with the length of the 'g' packet when
> using the new arm-eabi-gdb 7.3.1:
> 
>> (gdb) tar rem /dev/ttyS0
>> Remote debugging using /dev/ttyS0
>> Remote 'g' packet reply is too long: e14e000810000000000000001000000000000000000000000000000000000000000000000000000000000000fccf0d6800000000e8cf0d6895680008e24e00080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021
>> (gdb)
> 
> We will need to look into why the packet length has apparently changed
> for Cortex-M targets. I can connect to an ARM7 target using the new GDB
> without problem.

This is a mismatch between the number of registers a gdb server reports
and the number that gdb expects for the given architecture. In this case
too many registers are being reported. IIRC, there should be 8 hex
digits for a register, so the above string seems to represent 42
registers instead of the 21 that Cortex-M has. Looks like a bug in the
monitor stub code, or perhaps a work around for something broken in
older toolchains?

Tomas

headers

Tomas Frydrych | 5 Mar 2012 09:56

Re: eCos GNU tools 4.6.2-20120125 ready for testing

On 05/03/12 08:30, Tomas Frydrych wrote:
> On 04/03/12 19:37, John Dallaway wrote:
>> However, this success was achieved using arm-eabi-gdb 6.8.50.20080706.
>> There does appear to be an issue with the length of the 'g' packet when
>> using the new arm-eabi-gdb 7.3.1:
>>
>>> (gdb) tar rem /dev/ttyS0
>>> Remote debugging using /dev/ttyS0
>>> Remote 'g' packet reply is too long: e14e000810000000000000001000000000000000000000000000000000000000000000000000000000000000fccf0d6800000000e8cf0d6895680008e24e00080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021
>>> (gdb)
>>
>> We will need to look into why the packet length has apparently changed
>> for Cortex-M targets. I can connect to an ARM7 target using the new GDB
>> without problem.
> 
> This is a mismatch between the number of registers a gdb server reports
> and the number that gdb expects for the given architecture. In this case
> too many registers are being reported. IIRC, there should be 8 hex
> digits for a register, so the above string seems to represent 42
> registers instead of the 21 that Cortex-M has. Looks like a bug in the
> monitor stub code, or perhaps a work around for something broken in
> older toolchains?

Done bit further digging around the sources,
hal/cortexm/arch/.../cortexm_stub.h:64 defines 16 gpr, 8 fp or 12 bytes
each and 2 ps registers; this adds up to the 336 bytes of the above output.

Tomas

>

(Continue reading)

headers

John Dallaway | 5 Mar 2012 10:49

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi Tomas

Tomas Frydrych wrote:

> On 05/03/12 08:30, Tomas Frydrych wrote:
>> On 04/03/12 19:37, John Dallaway wrote:
>>> However, this success was achieved using arm-eabi-gdb 6.8.50.20080706.
>>> There does appear to be an issue with the length of the 'g' packet when
>>> using the new arm-eabi-gdb 7.3.1:
>>>
>>>> (gdb) tar rem /dev/ttyS0
>>>> Remote debugging using /dev/ttyS0
>>>> Remote 'g' packet reply is too long: e14e000810000000000000001000000000000000000000000000000000000000000000000000000000000000fccf0d6800000000e8cf0d6895680008e24e00080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021
>>>> (gdb)
>>> We will need to look into why the packet length has apparently changed
>>> for Cortex-M targets. I can connect to an ARM7 target using the new GDB
>>> without problem.
>> 
>> This is a mismatch between the number of registers a gdb server reports
>> and the number that gdb expects for the given architecture. In this case
>> too many registers are being reported. IIRC, there should be 8 hex
>> digits for a register, so the above string seems to represent 42
>> registers instead of the 21 that Cortex-M has. Looks like a bug in the
>> monitor stub code, or perhaps a work around for something broken in
>> older toolchains?
> 
> Done bit further digging around the sources,
> hal/cortexm/arch/.../cortexm_stub.h:64 defines 16 gpr, 8 fp or 12 bytes
> each and 2 ps registers; this adds up to the 336 bytes of the above output.

(Continue reading)

headers

Anders Montonen | 5 Mar 2012 10:55

Re: eCos GNU tools 4.6.2-20120125 ready for testing


On Mar 5, 2012, at 11:49, John Dallaway wrote:

> In the short term, I will look at creating a GDB target description file
> that we can use to accommodate the larger register set returned by our
> stubs.

Here's one I've been using when debugging via OpenOCD:
 <http://www.mail-archive.com/openocd-development <at> lists.berlios.de/msg18182.html>

-a

headers

John Dallaway | 5 Mar 2012 15:19

Re: eCos GNU tools 4.6.2-20120125 ready for testing

Hi Anders and all

Anders Montonen wrote:

> On Mar 5, 2012, at 11:49, John Dallaway wrote:
> 
>> In the short term, I will look at creating a GDB target description file
>> that we can use to accommodate the larger register set returned by our
>> stubs.
> 
> Here's one I've been using when debugging via OpenOCD:
>  <http://www.mail-archive.com/openocd-development <at> lists.berlios.de/msg18182.html>

Thank you for the pointer. That target description works fine for me,
but I noticed that it uses the org.gnu.gdb.arm.core feature which
describes the "cpsr" register. That register is named "xpsr" in GDB's
default M-profile feature:

http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/features/arm-m-profile.xml?rev=1.3&content-type=text/x-cvsweb-markup&cvsroot=src

It seems appropriate to use the org.gnu.gdb.arm.m-profile feature rather
than the org.gnu.gdb.arm.core feature and therefore adopt the register
naming used by current GDB for M-profile targets. However, this might
possibly cause problems for people who have existing GDB scripts
developed for arm-eabi-gdb 6.8.50.20080706 that reference the cpsr
register by name. Does anyone care about this?

John Dallaway
eCos maintainer
http://www.dallaway.org.uk/john

(Continue reading)

headers

Ilija Kocho | 5 Mar 2012 11:16

Re: eCos GNU tools 4.6.2-20120125 ready for testing

On 05.03.2012 10:49, John Dallaway wrote:
> Hi Tomas
>
> Tomas Frydrych wrote:
>
>> On 05/03/12 08:30, Tomas Frydrych wrote:
>>> On 04/03/12 19:37, John Dallaway wrote:
>>>> However, this success was achieved using arm-eabi-gdb 6.8.50.20080706.
>>>> There does appear to be an issue with the length of the 'g' packet when
>>>> using the new arm-eabi-gdb 7.3.1:
>>>>
>>>>> (gdb) tar rem /dev/ttyS0
>>>>> Remote debugging using /dev/ttyS0
>>>>> Remote 'g' packet reply is too long: e14e000810000000000000001000000000000000000000000000000000000000000000000000000000000000fccf0d6800000000e8cf0d6895680008e24e00080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021
>>>>> (gdb)
>>>> We will need to look into why the packet length has apparently changed
>>>> for Cortex-M targets. I can connect to an ARM7 target using the new GDB
>>>> without problem.
>>> This is a mismatch between the number of registers a gdb server reports
>>> and the number that gdb expects for the given architecture. In this case
>>> too many registers are being reported. IIRC, there should be 8 hex
>>> digits for a register, so the above string seems to represent 42
>>> registers instead of the 21 that Cortex-M has. Looks like a bug in the
>>> monitor stub code, or perhaps a work around for something broken in
>>> older toolchains?
>> Done bit further digging around the sources,
>> hal/cortexm/arch/.../cortexm_stub.h:64 defines 16 gpr, 8 fp or 12 bytes
>> each and 2 ps registers; this adds up to the 336 bytes of the above output.
> Yes. It looks like the FPA registers have been dropped from the default
> register set for Cortex-M targets in recent GDB. In the longer term, we

(Continue reading)

headers

Tomas Frydrych | 5 Mar 2012 13:56

Re: eCos GNU tools 4.6.2-20120125 ready for testing

On 05/03/12 10:16, Ilija Kocho wrote:
> On 05.03.2012 10:49, John Dallaway wrote:
>> Hi Tomas
>>
>> Tomas Frydrych wrote:
>>
>>> On 05/03/12 08:30, Tomas Frydrych wrote:
>>>> On 04/03/12 19:37, John Dallaway wrote:
>>>>> However, this success was achieved using arm-eabi-gdb 6.8.50.20080706.
>>>>> There does appear to be an issue with the length of the 'g' packet when
>>>>> using the new arm-eabi-gdb 7.3.1:
>>>>>
>>>>>> (gdb) tar rem /dev/ttyS0
>>>>>> Remote debugging using /dev/ttyS0
>>>>>> Remote 'g' packet reply is too long: e14e000810000000000000001000000000000000000000000000000000000000000000000000000000000000fccf0d6800000000e8cf0d6895680008e24e00080000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000021
>>>>>> (gdb)
>>>>> We will need to look into why the packet length has apparently changed
>>>>> for Cortex-M targets. I can connect to an ARM7 target using the new GDB
>>>>> without problem.
>>>> This is a mismatch between the number of registers a gdb server reports
>>>> and the number that gdb expects for the given architecture. In this case
>>>> too many registers are being reported. IIRC, there should be 8 hex
>>>> digits for a register, so the above string seems to represent 42
>>>> registers instead of the 21 that Cortex-M has. Looks like a bug in the
>>>> monitor stub code, or perhaps a work around for something broken in
>>>> older toolchains?
>>> Done bit further digging around the sources,
>>> hal/cortexm/arch/.../cortexm_stub.h:64 defines 16 gpr, 8 fp or 12 bytes
>>> each and 2 ps registers; this adds up to the 336 bytes of the above output.
>> Yes. It looks like the FPA registers have been dropped from the default

(Continue reading)

headers

Sergei Gavrikov | 3 Mar 2012 13:57

Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]

On Mon, 13 Feb 2012, Ilija Kocho wrote:

> eCos GNU tools 4.6.2-20120125 (arm_eabi) binaries are ready for
> testing.  John has placed them on FTP and by now most of the mirrors
> should have updated.

Hi Ilija

I'd got some results for ARM7 CPU with new toolchain(s).

Host:   i686-pc-linux-gnu
CPU:    ARM7TDMI
Target: olpch2294 (OLIMEX LPC-H2294)

The 234 eCos tests (1183 checks) were passed on the target using a fresh
build of RedBoot with new toolchain.

  +--------------+------+---------------+------+-------------+
  | Toolchain 1) | PASS | NOTAPPLICABLE | FAIL | RedBoot+GDB |
  +--------------+------+---------------+------+-------------+
  | GCC 4.6.2 2) | 1173 | 10            | 0    | OK 4)       |   
  | GCC 4.6.2 3) | 1173 | 10            | 0    | OK 4)       |
  | GCC 4.6.3 3) | 1173 | 10            | 0    | OK 4)       |
  +--------------+------+---------------+------+-------------+

  ---
  1) Binutils 2.22, GCC 4.6, GDB 7.3.1 
  2) Distributed binaries (ecos-gnutools-20120125)
  3) Toolchain built from sources
  4) Used serial debug/diagnistic channel (UART0 <at> 230400)

(Continue reading)

headers

Tomas Frydrych | 17 Jan 2012 10:36

Re: Gnutools: consideration for upgrade to GCC 4.6

Hi Ilija,

On 13/01/12 17:00, Ilija Kocho wrote:
> Regarding this, I state my wish that we move to the latest stable GCC
> release, that is at present rel. 4.6.2, accompanied with respective
> binutils. I have tested binutils 2.21 but in meantime 2.22 has been
> released. Of course, the list wouldn't be complete without the latest GDB.

Some of the more recent gccs were not producing usable binaries on some
platforms (including arm) with the -Os option. I do not know if this is
the case with 4.6.2, and I don't think ecos uses -Os by default, but it
is probably worth checking whether this works (and at least documenting
somewhere if it does not).

Tomas

headers

Stanislav Meduna | 17 Jan 2012 17:09

Re: Gnutools: consideration for upgrade to GCC 4.6

On 17.01.2012 10:36, Tomas Frydrych wrote:

> Some of the more recent gccs were not producing usable binaries on some
> platforms (including arm) with the -Os option. I do not know if this is
> the case with 4.6.2, and I don't think ecos uses -Os by default, but it
> is probably worth checking whether this works (and at least documenting
> somewhere if it does not).

Do you happen to have more details on this - versions, flags used,
example to reproduce...?

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html says

  -Os enables all -O2 optimizations that do not typically increase
  code size. It also performs further optimizations designed
  to reduce code size.

it would be good to know whether the problems come from -O2 (which
would be a major problem) or from these further optimizations.

FWIW, I am using -Os with 4.5.2 for Cortex-M3, but only for the
RedBoot that has to fit in the restricted space. Up to now I did not
experience any problems. I did not yet try 4.6.x.

--

-- 
                                       Stano

headers

Tomas Frydrych | 17 Jan 2012 17:25

Re: Gnutools: consideration for upgrade to GCC 4.6

Hi,

On 17/01/12 16:09, Stanislav Meduna wrote:
> On 17.01.2012 10:36, Tomas Frydrych wrote:
>> Some of the more recent gccs were not producing usable binaries on some
>> platforms (including arm) with the -Os option. I do not know if this is
>> the case with 4.6.2, and I don't think ecos uses -Os by default, but it
>> is probably worth checking whether this works (and at least documenting
>> somewhere if it does not).
> 
> Do you happen to have more details on this - versions, flags used,
> example to reproduce...?
> 
> http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html says
> 
>   -Os enables all -O2 optimizations that do not typically increase
>   code size. It also performs further optimizations designed
>   to reduce code size.
> 
> it would be good to know whether the problems come from -O2 (which
> would be a major problem) or from these further optimizations.

It was known to be present in gcc 4.5.1, and it was not effecting the
-O2 option, only -Os. The openembedded/yoctoproject guys run into it
building u-boot, and it was mentioned yesterday on the poky mailing
list,
https://lists.yoctoproject.org/pipermail/poky/2012-January/007472.html.

Tomas

(Continue reading)

headers

Ilija Kocho | 17 Jan 2012 17:44

Re: Gnutools: consideration for upgrade to GCC 4.6

On 17.01.2012 17:09, Stanislav Meduna wrote:
> On 17.01.2012 10:36, Tomas Frydrych wrote:
>
>> Some of the more recent gccs were not producing usable binaries on some
>> platforms (including arm) with the -Os option. I do not know if this is
>> the case with 4.6.2, and I don't think ecos uses -Os by default, but it
>> is probably worth checking whether this works (and at least documenting
>> somewhere if it does not).
> Do you happen to have more details on this - versions, flags used,
> example to reproduce...?
>
> http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html says
>
>    -Os enables all -O2 optimizations that do not typically increase
>    code size. It also performs further optimizations designed
>    to reduce code size.
>
> it would be good to know whether the problems come from -O2 (which
> would be a major problem) or from these further optimizations.

I am compiling with default eCos options (that include -O2). Haven't 
noticed a problems so far.

Ilija

headers

Frank Pagliughi | 20 Jan 2012 15:41

Re: Gnutools: consideration for upgrade to GCC 4.6

On 01/17/2012 11:44 AM, Ilija Kocho wrote:
> On 17.01.2012 17:09, Stanislav Meduna wrote:
>> On 17.01.2012 10:36, Tomas Frydrych wrote:
>>
>>> Some of the more recent gccs were not producing usable binaries on some
>>> platforms (including arm) with the -Os option. I do not know if this is
>>> the case with 4.6.2, and I don't think ecos uses -Os by default, but it
>>> is probably worth checking whether this works (and at least documenting
>>> somewhere if it does not).
>> Do you happen to have more details on this - versions, flags used,
>> example to reproduce...?
>>
>> http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html says
>>
>>    -Os enables all -O2 optimizations that do not typically increase
>>    code size. It also performs further optimizations designed
>>    to reduce code size.
>>
>> it would be good to know whether the problems come from -O2 (which
>> would be a major problem) or from these further optimizations.
>
> I am compiling with default eCos options (that include -O2). Haven't 
> noticed a problems so far.
>
>
> Ilija
>
It would be pretty cool if we made a script that downloaded and built 
the eCos GNU tools for the current "official" version. Add the script to 
the source control. That way we'd all have a good starting point when

(Continue reading)