public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
* Gnutools: consideration for upgrade to GCC 4.6
@ 2012-01-13 17:01 Ilija Kocho
  2012-01-13 18:54 ` Bernard Fouché
                   ` (3 more replies)
  0 siblings, 4 replies; 76+ messages in thread
From: Ilija Kocho @ 2012-01-13 17:01 UTC (permalink / raw)
  To: eCos developers

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-13 17:01 Gnutools: consideration for upgrade to GCC 4.6 Ilija Kocho
@ 2012-01-13 18:54 ` Bernard Fouché
  2012-01-13 19:39   ` Ilija Kocho
  2012-01-13 19:09 ` Frank Pagliughi
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 76+ messages in thread
From: Bernard Fouché @ 2012-01-13 18:54 UTC (permalink / raw)
  To: ecos-devel


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.

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-13 17:01 Gnutools: consideration for upgrade to GCC 4.6 Ilija Kocho
  2012-01-13 18:54 ` Bernard Fouché
@ 2012-01-13 19:09 ` Frank Pagliughi
  2012-01-13 19:45   ` Ilija Kocho
  2012-01-14 10:22 ` John Dallaway
  2012-01-17  9:37 ` Gnutools: consideration for upgrade to GCC 4.6 Tomas Frydrych
  3 siblings, 1 reply; 76+ messages in thread
From: Frank Pagliughi @ 2012-01-13 19:09 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: eCos developers

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.

So far I've been very happy, but I was mostly concerned with language 
features. The additional Cortex support sells it, though. I'm just 
starting to start shopping around for a Cortex-M3 for my next project.

Frank

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-13 18:54 ` Bernard Fouché
@ 2012-01-13 19:39   ` Ilija Kocho
  0 siblings, 0 replies; 76+ messages in thread
From: Ilija Kocho @ 2012-01-13 19:39 UTC (permalink / raw)
  To: ecos-devel

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-13 19:09 ` Frank Pagliughi
@ 2012-01-13 19:45   ` Ilija Kocho
  0 siblings, 0 replies; 76+ messages in thread
From: Ilija Kocho @ 2012-01-13 19:45 UTC (permalink / raw)
  To: ecos-devel

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 
> compiler. I used binutils 2.21.1.

I was using 2.21.1, but toady I tried 2.22. It works out of box, no 
patching.

>
> So far I've been very happy, but I was mostly concerned with language 
> features. The additional Cortex support sells it, though. I'm just 
> starting to start shopping around for a Cortex-M3 for my next project.

If you are happy with ARM7TDMI you'll be happier with Cortex-M

Ilija

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-13 17:01 Gnutools: consideration for upgrade to GCC 4.6 Ilija Kocho
  2012-01-13 18:54 ` Bernard Fouché
  2012-01-13 19:09 ` Frank Pagliughi
@ 2012-01-14 10:22 ` John Dallaway
  2012-01-14 16:02   ` Sergei Gavrikov
  2012-01-14 16:25   ` Ilija Kocho
  2012-01-17  9:37 ` Gnutools: consideration for upgrade to GCC 4.6 Tomas Frydrych
  3 siblings, 2 replies; 76+ messages in thread
From: John Dallaway @ 2012-01-14 10:22 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: eCos developers

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:

  ftp://ecos.sourceware.org/pub/ecos/gnutools/src/

It would be useful to review these and determine which are still
relevant. Certainly we would need to adjust the multi-libbing for some
target architectures.

It would also be useful to test eCos with the new toolchain in an
automated manner. I wonder if one of the maintainers at eCosCentric
could set up testing in their test farm? In any case, I would advocate a
cautious approach to roll out, creating an initial "test release" for
use mostly by those interested in the new features. We could also
consider building the toolchain for arm-eabi targets only in the first
instance to reduce overall effort. Does anyone on this list have a
particular interest in building eCos with recent GCC for another target
architecture?

It would be important to retain eCos source compatibility with the
current toolchains based on GCC 4.3.2.

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-14 10:22 ` John Dallaway
@ 2012-01-14 16:02   ` Sergei Gavrikov
  2012-01-15 17:36     ` Grant Edwards
  2012-01-23  0:59     ` Jonathan Larmour
  2012-01-14 16:25   ` Ilija Kocho
  1 sibling, 2 replies; 76+ messages in thread
From: Sergei Gavrikov @ 2012-01-14 16:02 UTC (permalink / raw)
  To: John Dallaway; +Cc: Ilija Kocho, eCos developers

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.
> 
> 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:
> 
>   ftp://ecos.sourceware.org/pub/ecos/gnutools/src/
> 
> It would be useful to review these and determine which are still
> relevant. Certainly we would need to adjust the multi-libbing for some
> target architectures.

Also we would take a look at the RTEMS (CVS -> 4.11) patches for their
latest toolchain sources as they does use GCC 4.6.1 & binutils 2.21 for
RTEMS (CVS) builds

  http://www.rtems.org/ftp/pub/rtems/SOURCES/4.11/
  
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. What do you think?

IMHO, we also would start to use own labels in the prefixes for eCos
toolchains (http://gcc.gnu.org/install/specific.html). What do you think
about 'ecos' label in the prefixes as an OS-label? In ideal world the
prefixes would be *-*-ecos2.0, *-*-ecos3.0, *-*-ecos4.0 for toolchains
for eCos major releases to prevent the PATH collisions, and, perhaps,
*-*-ecos<major>.<year>, for eCos middle time (not full tested) releases,
e.g.  i386-elf-ecos3.12-gcc for 2012. And may be to have *-*-ecos as the
prefixes is quite enough for us. (Excuse, if above looks like
OFF-TOPIC).

> It would also be useful to test eCos with the new toolchain in an
> automated manner. I wonder if one of the maintainers at eCosCentric
> could set up testing in their test farm? In any case, I would advocate
> a cautious approach to roll out, creating an initial "test release"
> for use mostly by those interested in the new features. We could also
> consider building the toolchain for arm-eabi targets only in the first
> instance to reduce overall effort. Does anyone on this list have a
> particular interest in building eCos with recent GCC for another
> target architecture?

IMHO, if we won't see volunteers for non arm-eabi targets also we should
test new toolchain for Linux synthetic target at least (it would help us
in the efforts on warning clean-ups for new toolchain).

Sergei

> It would be important to retain eCos source compatibility with the
> current toolchains based on GCC 4.3.2.
> 
> John Dallaway
> eCos maintainer
> http://www.dallaway.org.uk/john
> 

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-14 10:22 ` John Dallaway
  2012-01-14 16:02   ` Sergei Gavrikov
@ 2012-01-14 16:25   ` Ilija Kocho
  2012-01-23  1:13     ` Jonathan Larmour
  1 sibling, 1 reply; 76+ messages in thread
From: Ilija Kocho @ 2012-01-14 16:25 UTC (permalink / raw)
  To: John Dallaway; +Cc: eCos developers

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

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

> Certainly we would need to adjust the multi-libbing for some
> target architectures.
>
> It would also be useful to test eCos with the new toolchain in an
> automated manner. I wonder if one of the maintainers at eCosCentric
> could set up testing in their test farm? In any case, I would advocate a
> cautious approach to roll out, creating an initial "test release" for
> use mostly by those interested in the new features.

This is a good approach. During the "test period" we can fix the 
warnings, etc.

> We could also
> consider building the toolchain for arm-eabi targets only in the first
> instance to reduce overall effort. Does anyone on this list have a
> particular interest in building eCos with recent GCC for another target
> architecture?
>
> It would be important to retain eCos source compatibility with the
> current toolchains based on GCC 4.3.2.

This probably shall not be a (big) problem. GCC 4.6 (be it minor 0, 1 or 
2) doesn't seem to require any changes other than elimination of 
warnings. From my experience, everything that works with GCC 4.3.2 also 
works with GCC 4.6. Of course some backward compatibility break is 
inevitable. The build options for new architectures are not supported by 
older versions (example -mcpu=cortex-m4). But that's why we're looking 
for the upgrade in the first place :) .

Ilija Kocho

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-14 16:02   ` Sergei Gavrikov
@ 2012-01-15 17:36     ` Grant Edwards
  2012-01-15 18:42       ` Sergei Gavrikov
  2012-01-23  0:59     ` Jonathan Larmour
  1 sibling, 1 reply; 76+ messages in thread
From: Grant Edwards @ 2012-01-15 17:36 UTC (permalink / raw)
  To: ecos-devel

On 2012-01-14, Sergei Gavrikov <sergei.gavrikov@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




^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-15 17:36     ` Grant Edwards
@ 2012-01-15 18:42       ` Sergei Gavrikov
  2012-01-15 21:39         ` Stanislav Meduna
                           ` (3 more replies)
  0 siblings, 4 replies; 76+ messages in thread
From: Sergei Gavrikov @ 2012-01-15 18:42 UTC (permalink / raw)
  To: Grant Edwards; +Cc: ecos-devel

On Sun, 15 Jan 2012, Grant Edwards wrote:

> On 2012-01-14, Sergei Gavrikov <sergei.gavrikov@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
  ...
  #endif

For now we usually add '-D__ECOS__' to CFLAGS for some packages.

The third, Why we should avoid to say that eCos is also well known,
widely used OS?

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

Nope. Anyone can use own binaries if he/she wants.
 
> 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.

Why it will be not possible? I did not understand. You can use own, but,
a bug reporter should/may use officially supported "labeled" toolchain
to check the roots of some issue on crashes. But, naturally, I do not
resists on built-in label __ecos__. Look on that as a promotion eCos OS.
If you think that my points are wrong, please, forget it.

Thanks for your comments.

Sergei

> Grant
> 
> 
> 
> 

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-15 18:42       ` Sergei Gavrikov
@ 2012-01-15 21:39         ` Stanislav Meduna
  2012-01-23  1:01           ` Jonathan Larmour
  2012-01-15 22:21         ` Ilija Kocho
                           ` (2 subsequent siblings)
  3 siblings, 1 reply; 76+ messages in thread
From: Stanislav Meduna @ 2012-01-15 21:39 UTC (permalink / raw)
  To: ecos-devel

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

Regards
-- 
                                          Stano

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-15 18:42       ` Sergei Gavrikov
  2012-01-15 21:39         ` Stanislav Meduna
@ 2012-01-15 22:21         ` Ilija Kocho
  2012-01-15 22:21         ` Ilija Kocho
  2012-01-16 15:20         ` Grant Edwards
  3 siblings, 0 replies; 76+ messages in thread
From: Ilija Kocho @ 2012-01-15 22:21 UTC (permalink / raw)
  To: ecos-devel

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@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
>    ...
>    #endif
>
> For now we usually add '-D__ECOS__' to CFLAGS for some packages.
>
> The third, Why we should avoid to say that eCos is also well known,
> widely used OS?

It seems there have been some attempts before as there are some traces 
left in gcc tree:
gcc/config/arm/ecos-elf.h

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

Speaking of branding, we shouldn't omit --version banner 
(|--with-pkgversion|), let's say "eCos community edition [<ver>]"

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

Ilija

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-15 18:42       ` Sergei Gavrikov
  2012-01-15 21:39         ` Stanislav Meduna
  2012-01-15 22:21         ` Ilija Kocho
@ 2012-01-15 22:21         ` Ilija Kocho
  2012-01-23  1:07           ` Jonathan Larmour
  2012-01-16 15:20         ` Grant Edwards
  3 siblings, 1 reply; 76+ messages in thread
From: Ilija Kocho @ 2012-01-15 22:21 UTC (permalink / raw)
  To: ecos-devel

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@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
>    ...
>    #endif
>
> For now we usually add '-D__ECOS__' to CFLAGS for some packages.
>
> The third, Why we should avoid to say that eCos is also well known,
> widely used OS?

It seems there have been some attempts before as there are some traces 
left in gcc tree:
gcc/config/arm/ecos-elf.h

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

Speaking of branding, we shouldn't omit --version banner 
(|--with-pkgversion|), let's say "eCos community edition [<ver>]"

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

Ilija

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-15 18:42       ` Sergei Gavrikov
                           ` (2 preceding siblings ...)
  2012-01-15 22:21         ` Ilija Kocho
@ 2012-01-16 15:20         ` Grant Edwards
  2012-01-16 20:43           ` Sergei Gavrikov
  3 siblings, 1 reply; 76+ messages in thread
From: Grant Edwards @ 2012-01-16 15:20 UTC (permalink / raw)
  To: ecos-devel

On 2012-01-15, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
> On Sun, 15 Jan 2012, Grant Edwards wrote:
>
>> On 2012-01-14, Sergei Gavrikov <sergei.gavrikov@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__
>   # include <endian.h>
>   #elif __ecos__
>   # include <machine/endian.h>
>   #else
>   ...
>   #endif

That doesn't seem to be appropriate to me.  In eCos builds, the
include files are not part of the toolchain and their locations
shouldn't be determined based on the toolchain.  The eCos include
files are part of the eCos source tree and build system (which
provides __ECOS__).

> For now we usually add '-D__ECOS__' to CFLAGS for some packages.
>
> The third, Why we should avoid to say that eCos is also well known,
> widely used OS?

For one thing, I use the same toolchain to build eCos stuff and
non-eCos stuff.  The __ECOS__ macro can be used to tell the
difference.

>> Are the eCos sources going to start requiring use of specific
>> toolchain binaries?
>
> Nope. Anyone can use own binaries if he/she wants.

Not if eCos code is going to contain checks for __ecos__ that cause a
build to fail without __ecos__.

>> 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.
>
> Why it will be not possible? I did not understand.

If the eCos code is going to be checking for __ecos__ then that code
won't build with my toolchains.

> You can use own, but, a bug reporter should/may use officially
> supported "labeled" toolchain to check the roots of some issue on
> crashes. But, naturally, I do not resists on built-in label __ecos__.
> Look on that as a promotion eCos OS. If you think that my points are
> wrong, please, forget it.

As long as nothing in the build process checks for or requires
__ecos__, then that's fine.

-- 
Grant Edwards               grant.b.edwards        Yow! Hey, wait
                                  at               a minute!!  I want a
                              gmail.com            divorce!! ... you're not
                                                   Clint Eastwood!!

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-16 15:20         ` Grant Edwards
@ 2012-01-16 20:43           ` Sergei Gavrikov
  2012-01-16 21:11             ` Sergei Gavrikov
  0 siblings, 1 reply; 76+ messages in thread
From: Sergei Gavrikov @ 2012-01-16 20:43 UTC (permalink / raw)
  To: Grant Edwards; +Cc: ecos-devel

On Mon, 16 Jan 2012, Grant Edwards wrote:

> On 2012-01-15, Sergei Gavrikov <sergei.gavrikov@gmail.com> wrote:
> > On Sun, 15 Jan 2012, Grant Edwards wrote:
> >
> >> On 2012-01-14, Sergei Gavrikov <sergei.gavrikov@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__
> >   # include <endian.h>
> >   #elif __ecos__
> >   # include <machine/endian.h>
> >   #else
> >   ...
> >   #endif
> 
> That doesn't seem to be appropriate to me.  In eCos builds, the
> include files are not part of the toolchain and their locations
> shouldn't be determined based on the toolchain.  The eCos include
> files are part of the eCos source tree and build system (which
> provides __ECOS__).

I agree, snippet above does confuse most of you. I would defend it, but,
I do not want to do so as I do not desire to change the *Subject* of
this thread.  (I'm sorry Ilija)

> > For now we usually add '-D__ECOS__' to CFLAGS for some packages.

To be clear, I did not offer neither to remove nor replace -D__ECOS__
from CFLAGS in eCos config files. I'm sorry if you've seen this.

> > The third, Why we should avoid to say that eCos is also well known,
> > widely used OS?
> 
> For one thing, I use the same toolchain to build eCos stuff and
> non-eCos stuff.  The __ECOS__ macro can be used to tell the
> difference.
> 
> >> Are the eCos sources going to start requiring use of specific
> >> toolchain binaries?
> >
> > Nope. Anyone can use own binaries if he/she wants.
> 
> Not if eCos code is going to contain checks for __ecos__ that cause a
> build to fail without __ecos__.

I ever did not think about. I did not plan to implant such checks in
*eCos sources*.  I did not say, we should  s/__ECOS__/__ecos__/g.  I
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.

> >> 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.
> >
> > Why it will be not possible? I did not understand.
> 
> If the eCos code is going to be checking for __ecos__ then that code
> won't build with my toolchains.

Once again that was not attempt of any revisionism for eCos sources.
IMHO, built-in CPP definition (__ecos__) can be useful a) for portable
userland applications (not eCos sources); b) for shell scripts which
would detect toolchain easier; c) to distinguish home cooked or third
party toolchains from eCos stable ones (that was my main idea). I risk
to paste yet another check

    /*
     * NOTE: I do not offer such a check for eCos sources itself.
     */
  #ifdef __ECOS__
  # if !defined(__ecos__)
  #  warn Used wrong toolchain for mission critical application.
  #  BUG()
  # endif
  #endif

But. Can such check exist in userland application? [Not need to answer]

> > You can use own, but, a bug reporter should/may use officially
> > supported "labeled" toolchain to check the roots of some issue on
> > crashes. But, naturally, I do not resists on built-in label
> > __ecos__.  Look on that as a promotion eCos OS. If you think that my
> > points are wrong, please, forget it.
> 
> As long as nothing in the build process checks for or requires
> __ecos__, then that's fine.

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" :-)

Let's move on to the subject of the thread. It seemed for me that all of
us are interested in new toolchain(s) and if you are the experts here,
let's open Bugzilla entry for this, there we would accumulate a set of
patches for new toolchain base.

Sergei

> -- 
> Grant Edwards               grant.b.edwards        Yow! Hey, wait
>                                   at               a minute!!  I want a
>                               gmail.com            divorce!! ... you're not
>                                                    Clint Eastwood!!
> 

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-16 20:43           ` Sergei Gavrikov
@ 2012-01-16 21:11             ` Sergei Gavrikov
  2012-01-17  9:58               ` Bernard Fouché
  0 siblings, 1 reply; 76+ messages in thread
From: Sergei Gavrikov @ 2012-01-16 21:11 UTC (permalink / raw)
  To: ecos-devel

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-13 17:01 Gnutools: consideration for upgrade to GCC 4.6 Ilija Kocho
                   ` (2 preceding siblings ...)
  2012-01-14 10:22 ` John Dallaway
@ 2012-01-17  9:37 ` Tomas Frydrych
  2012-01-17 16:10   ` Stanislav Meduna
  3 siblings, 1 reply; 76+ messages in thread
From: Tomas Frydrych @ 2012-01-17  9:37 UTC (permalink / raw)
  To: ecos-devel

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-16 21:11             ` Sergei Gavrikov
@ 2012-01-17  9:58               ` Bernard Fouché
  2012-01-17 10:38                 ` Paul Beskeen
  0 siblings, 1 reply; 76+ messages in thread
From: Bernard Fouché @ 2012-01-17  9:58 UTC (permalink / raw)
  To: ecos-devel


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
> is probably worth checking whether this works (and at least documenting
> somewhere if it does not).
>
> Tomas

     Bernard

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-17  9:58               ` Bernard Fouché
@ 2012-01-17 10:38                 ` Paul Beskeen
  2012-01-17 12:28                   ` Sergei Gavrikov
  0 siblings, 1 reply; 76+ messages in thread
From: Paul Beskeen @ 2012-01-17 10:38 UTC (permalink / raw)
  To: ecos-devel

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.

Regards, Paul.
--
Paul Beskeen, Chairman & Director of Engineering
http://www.ecoscentric.com/

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-17 10:38                 ` Paul Beskeen
@ 2012-01-17 12:28                   ` Sergei Gavrikov
  0 siblings, 0 replies; 76+ messages in thread
From: Sergei Gavrikov @ 2012-01-17 12:28 UTC (permalink / raw)
  To: Paul Beskeen; +Cc: ecos-devel

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1981 bytes --]

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
> > 
> > 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.
> 
> Regards, Paul.
> --
> Paul Beskeen, Chairman & Director of Engineering
> http://www.ecoscentric.com/
> 

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-17  9:37 ` Gnutools: consideration for upgrade to GCC 4.6 Tomas Frydrych
@ 2012-01-17 16:10   ` Stanislav Meduna
  2012-01-17 16:25     ` Tomas Frydrych
  2012-01-17 16:45     ` Ilija Kocho
  0 siblings, 2 replies; 76+ messages in thread
From: Stanislav Meduna @ 2012-01-17 16:10 UTC (permalink / raw)
  To: ecos-devel

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-17 16:10   ` Stanislav Meduna
@ 2012-01-17 16:25     ` Tomas Frydrych
  2012-01-17 16:45     ` Ilija Kocho
  1 sibling, 0 replies; 76+ messages in thread
From: Tomas Frydrych @ 2012-01-17 16:25 UTC (permalink / raw)
  To: ecos-devel

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


^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-17 16:10   ` Stanislav Meduna
  2012-01-17 16:25     ` Tomas Frydrych
@ 2012-01-17 16:45     ` Ilija Kocho
  2012-01-20 14:42       ` Frank Pagliughi
  1 sibling, 1 reply; 76+ messages in thread
From: Ilija Kocho @ 2012-01-17 16:45 UTC (permalink / raw)
  To: ecos-devel

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-17 16:45     ` Ilija Kocho
@ 2012-01-20 14:42       ` Frank Pagliughi
  0 siblings, 0 replies; 76+ messages in thread
From: Frank Pagliughi @ 2012-01-20 14:42 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: ecos-devel

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 
upgrading personal tool chains. And, while we're at it, update the 
ancient directions on the web site on how to build a tool chain:
     http://ecos.sourceware.org/build-toolchain.html

Frank

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-14 16:02   ` Sergei Gavrikov
  2012-01-15 17:36     ` Grant Edwards
@ 2012-01-23  0:59     ` Jonathan Larmour
  1 sibling, 0 replies; 76+ messages in thread
From: Jonathan Larmour @ 2012-01-23  0:59 UTC (permalink / raw)
  To: Sergei Gavrikov; +Cc: eCos developers

On 14/01/12 16:01, Sergei Gavrikov wrote:
> 
> Also we would take a look at the RTEMS (CVS -> 4.11) patches for their
> latest toolchain sources as they does use GCC 4.6.1 & binutils 2.21 for
> RTEMS (CVS) builds
> 
>   http://www.rtems.org/ftp/pub/rtems/SOURCES/4.11/
>   
> 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. What do you think?

For reasons other people mentioned, I'd be against this.

> IMHO, we also would start to use own labels in the prefixes for eCos
> toolchains (http://gcc.gnu.org/install/specific.html). What do you think
> about 'ecos' label in the prefixes as an OS-label? In ideal world the
> prefixes would be *-*-ecos2.0, *-*-ecos3.0, *-*-ecos4.0 for toolchains
> for eCos major releases to prevent the PATH collisions, and, perhaps,
> *-*-ecos<major>.<year>, for eCos middle time (not full tested) releases,
> e.g.  i386-elf-ecos3.12-gcc for 2012. And may be to have *-*-ecos as the
> prefixes is quite enough for us. (Excuse, if above looks like
> OFF-TOPIC).

No, definitely nothing with versions in the tuple like that. There could
be an argument for a ARCH-ecos-elf tuple, for example. arm-eabi-ecos-elf.
But it's not a very good argument. We risk breaking backward
compatibility, and also compatibility with important toolchain providers
such as Codesourcery, who provide toolchains aimed at the newlib runtime,
but which eCos users can nevertheless use. We would no longer be able to
do that. Asking those eCos users to rebuild the toolchain for the eCos OS
target would not be right as Codesourcery support toolchain binaries, and
not rebuilt toolchains, even from the same source base.

> IMHO, if we won't see volunteers for non arm-eabi targets also we should
> test new toolchain for Linux synthetic target at least (it would help us
> in the efforts on warning clean-ups for new toolchain).

The Linux synthetic target uses the native toolchain, and as we've found
from bitter experience, different distros add their own wacky patches
(yes, Ubuntu and friends, I'm looking at you). People can look at warnings
on any architecture - you don't have to have a board after all just to
compile.

Jifl

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-15 21:39         ` Stanislav Meduna
@ 2012-01-23  1:01           ` Jonathan Larmour
  0 siblings, 0 replies; 76+ messages in thread
From: Jonathan Larmour @ 2012-01-23  1:01 UTC (permalink / raw)
  To: Stanislav Meduna; +Cc: ecos-devel

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-15 22:21         ` Ilija Kocho
@ 2012-01-23  1:07           ` Jonathan Larmour
  0 siblings, 0 replies; 76+ messages in thread
From: Jonathan Larmour @ 2012-01-23  1:07 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: ecos-devel

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.

Jifl

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-14 16:25   ` Ilija Kocho
@ 2012-01-23  1:13     ` Jonathan Larmour
  2012-01-23 18:40       ` Ilija Kocho
  0 siblings, 1 reply; 76+ messages in thread
From: Jonathan Larmour @ 2012-01-23  1:13 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: eCos developers

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-23  1:13     ` Jonathan Larmour
@ 2012-01-23 18:40       ` Ilija Kocho
  2012-01-23 19:29         ` Jonathan Larmour
  2012-01-25 12:30         ` Alex Schuilenburg
  0 siblings, 2 replies; 76+ messages in thread
From: Ilija Kocho @ 2012-01-23 18:40 UTC (permalink / raw)
  To: Jonathan Larmour; +Cc: eCos developers

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.

This one :

--- gcc-4.3.2.clean/gcc/config/arm/arm.h    2008-09-22 
19:41:47.000000000 +0100
+++ gcc-4.3.2/gcc/config/arm/arm.h    2008-10-03 22:54:49.000000000 +0100
@@ -194,7 +194,7 @@ extern void (*arm_lang_output_object_att
  #define TARGET_BACKTRACE            (leaf_function_p () \
                           ? TARGET_TPCS_LEAF_FRAME \
                           : TARGET_TPCS_FRAME)
-#define TARGET_LDRD            (arm_arch5e && ARM_DOUBLEWORD_ALIGN)
+#define TARGET_LDRD            (0) /* arm_arch5e && 
ARM_DOUBLEWORD_ALIGN) */
  #define TARGET_AAPCS_BASED \
      (arm_abi != ARM_ABI_APCS && arm_abi != ARM_ABI_ATPCS)

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.


Ilija

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-23 18:40       ` Ilija Kocho
@ 2012-01-23 19:29         ` Jonathan Larmour
  2012-01-25 12:30         ` Alex Schuilenburg
  1 sibling, 0 replies; 76+ messages in thread
From: Jonathan Larmour @ 2012-01-23 19:29 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: eCos developers

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@ecoscentric) it was first discovered when doing the port.

Jifl

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-23 18:40       ` Ilija Kocho
  2012-01-23 19:29         ` Jonathan Larmour
@ 2012-01-25 12:30         ` Alex Schuilenburg
  2012-01-25 20:59           ` Ilija Kocho
  2012-02-13 22:02           ` eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] Ilija Kocho
  1 sibling, 2 replies; 76+ messages in thread
From: Alex Schuilenburg @ 2012-01-25 12:30 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: eCos developers

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
    preserved and made available along with the test binary, although
    the full output of special tests such as tm_basic are also always
    made available.
 3. eCos test result summary
    The number of passes and number of each type of failure for each
    build is presented in table form to provide an overview of the test
    results for the build.

All we need from you is a Linux hosted arm-eabi toolchain in tarball
form and the eCos sources, also in tarball form, although we can use
http://hg-pub.ecoscentric.com/ecos as the source base if you prefer.

If you would like to make use of the test farm and agree with the
selection of targets (or can propose alternatives), please let me know
and provide me with the url where the toolchain can be downloaded from
(and optionally the sources).  I'll post the results as soon as the
tests are completed.

Cheers

--  Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com             Reg in England and Wales, Reg No 4422071


^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-25 12:30         ` Alex Schuilenburg
@ 2012-01-25 20:59           ` Ilija Kocho
  2012-01-26 13:36             ` Alex Schuilenburg
  2012-02-13 22:02           ` eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] Ilija Kocho
  1 sibling, 1 reply; 76+ messages in thread
From: Ilija Kocho @ 2012-01-25 20:59 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: eCos developers

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:
> 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
>      preserved and made available along with the test binary, although
>      the full output of special tests such as tm_basic are also always
>      made available.
>   3. eCos test result summary
>      The number of passes and number of each type of failure for each
>      build is presented in table form to provide an overview of the test
>      results for the build.
>
> All we need from you is a Linux hosted arm-eabi toolchain in tarball
> form and the eCos sources, also in tarball form, although we can use
> http://hg-pub.ecoscentric.com/ecos as the source base if you prefer.
>
> If you would like to make use of the test farm and agree with the
> selection of targets (or can propose alternatives), please let me know
> and provide me with the url where the toolchain can be downloaded from
> (and optionally the sources).  I'll post the results as soon as the
> tests are completed.
>
> Cheers
>
> --  Alex Schuilenburg
>
> Managing Director/CEO                                eCosCentric Limited
> www.ecoscentric.com             Reg in England and Wales, Reg No 4422071
>
>

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-25 20:59           ` Ilija Kocho
@ 2012-01-26 13:36             ` Alex Schuilenburg
  2012-01-26 20:18               ` Ilija Kocho
  0 siblings, 1 reply; 76+ messages in thread
From: Alex Schuilenburg @ 2012-01-26 13:36 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: eCos developers

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.


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

That is interesting.  However the two boards I suggested are ones we
physically have so can build and run tests for and are conveniently
currently located in our test farm. We don't have a Freescale K70.  The
publicly available boards we do have can be found at
http://www.ecoscentric.com/ecos/ecospro_tab.shtml, although not all may
be available in our test farm. Is there board in this list you may think
may be better for testing for which a public eCos BSP exists?

Cheers

-- Alex Schuilenburg

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com             Reg in England and Wales, Reg No 4422071

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: Gnutools: consideration for upgrade to GCC 4.6
  2012-01-26 13:36             ` Alex Schuilenburg
@ 2012-01-26 20:18               ` Ilija Kocho
  0 siblings, 0 replies; 76+ messages in thread
From: Ilija Kocho @ 2012-01-26 20:18 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: eCos developers

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.

Thank you for clarification. This gives a completely new perspective. 
We'll take care "as many" to be some reasonable figure.

Cheers

Ilija

^ permalink raw reply	[flat|nested] 76+ messages in thread

* eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]
  2012-01-25 12:30         ` Alex Schuilenburg
  2012-01-25 20:59           ` Ilija Kocho
@ 2012-02-13 22:02           ` Ilija Kocho
  2012-02-20 16:00             ` Alex Schuilenburg
                               ` (2 more replies)
  1 sibling, 3 replies; 76+ messages in thread
From: Ilija Kocho @ 2012-02-13 22:02 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: eCos developers

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
> 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
>     preserved and made available along with the test binary, although
>     the full output of special tests such as tm_basic are also always
>     made available.
>  3. eCos test result summary
>     The number of passes and number of each type of failure for each
>     build is presented in table form to provide an overview of the test
>     results for the build.
>
> All we need from you is a Linux hosted arm-eabi toolchain in tarball
> form and the eCos sources, also in tarball form, although we can use
> http://hg-pub.ecoscentric.com/ecos as the source base if you prefer.
>
> If you would like to make use of the test farm and agree with the
> selection of targets (or can propose alternatives), please let me know
> and provide me with the url where the toolchain can be downloaded from
> (and optionally the sources).  I'll post the results as soon as the
> tests are completed.
>
> Cheers
>
> --  Alex Schuilenburg
>
> Managing Director/CEO                                eCosCentric Limited
> www.ecoscentric.com             Reg in England and Wales, Reg No 4422071
>
>
>

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]
  2012-02-13 22:02           ` eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] Ilija Kocho
@ 2012-02-20 16:00             ` Alex Schuilenburg
  2012-02-20 20:45               ` Ilija Kocho
  2012-03-02 16:36             ` Alex Schuilenburg
  2012-03-03 12:58             ` eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] Sergei Gavrikov
  2 siblings, 1 reply; 76+ messages in thread
From: Alex Schuilenburg @ 2012-02-20 16:00 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: Alex Schuilenburg, eCos developers

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
>
>
>
> 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
>> 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
>>     preserved and made available along with the test binary, although
>>     the full output of special tests such as tm_basic are also always
>>     made available.
>>  3. eCos test result summary
>>     The number of passes and number of each type of failure for each
>>     build is presented in table form to provide an overview of the test
>>     results for the build.
>>
>> All we need from you is a Linux hosted arm-eabi toolchain in tarball
>> form and the eCos sources, also in tarball form, although we can use
>> http://hg-pub.ecoscentric.com/ecos as the source base if you prefer.
>>
>> If you would like to make use of the test farm and agree with the
>> selection of targets (or can propose alternatives), please let me know
>> and provide me with the url where the toolchain can be downloaded from
>> (and optionally the sources).  I'll post the results as soon as the
>> tests are completed.
>>
>> Cheers
>>
>> --  Alex Schuilenburg
>>
>> Managing Director/CEO                                eCosCentric Limited
>> www.ecoscentric.com             Reg in England and Wales, Reg No 4422071
>>
>>
>>
>


^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]
  2012-02-20 16:00             ` Alex Schuilenburg
@ 2012-02-20 20:45               ` Ilija Kocho
  0 siblings, 0 replies; 76+ messages in thread
From: Ilija Kocho @ 2012-02-20 20:45 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: eCos developers

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

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


[-- Attachment #2: ustl_with_fileio.ecm --]
[-- Type: text/plain, Size: 124 bytes --]

cdl_configuration eCos {
    template default ;
    package CYGPKG_USTL current ;
    package CYGPKG_IO_FILEIO current ;
};

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]
  2012-02-13 22:02           ` eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] Ilija Kocho
  2012-02-20 16:00             ` Alex Schuilenburg
@ 2012-03-02 16:36             ` Alex Schuilenburg
  2012-03-03 13:32               ` Ilija Kocho
  2012-03-03 12:58             ` eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] Sergei Gavrikov
  2 siblings, 1 reply; 76+ messages in thread
From: Alex Schuilenburg @ 2012-03-02 16:36 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: eCos developers

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


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

I have added the configuration you sent to our test farm, although
obviously because the sources are eCosPro, there is no uSTL support
testing for the Embedded Artists LPC2468-32.

I'll let you know how we get on with the ST STM3210E-EVAL board testing.

Cheers
-- Alex
Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com             Reg in England and Wales, Reg No 4422071



>
> 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
>> 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
>>     preserved and made available along with the test binary, although
>>     the full output of special tests such as tm_basic are also always
>>     made available.
>>  3. eCos test result summary
>>     The number of passes and number of each type of failure for each
>>     build is presented in table form to provide an overview of the test
>>     results for the build.
>>
>> All we need from you is a Linux hosted arm-eabi toolchain in tarball
>> form and the eCos sources, also in tarball form, although we can use
>> http://hg-pub.ecoscentric.com/ecos as the source base if you prefer.
>>
>> If you would like to make use of the test farm and agree with the
>> selection of targets (or can propose alternatives), please let me know
>> and provide me with the url where the toolchain can be downloaded from
>> (and optionally the sources).  I'll post the results as soon as the
>> tests are completed.
>>
>> Cheers
>>
>> --  Alex Schuilenburg
>>
>> Managing Director/CEO                                eCosCentric Limited
>> www.ecoscentric.com             Reg in England and Wales, Reg No 4422071
>>
>>
>>


^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]
  2012-02-13 22:02           ` eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] Ilija Kocho
  2012-02-20 16:00             ` Alex Schuilenburg
  2012-03-02 16:36             ` Alex Schuilenburg
@ 2012-03-03 12:58             ` Sergei Gavrikov
  2 siblings, 0 replies; 76+ messages in thread
From: Sergei Gavrikov @ 2012-03-03 12:58 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: Alex Schuilenburg, eCos developers

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@230400)
     No issues with GDB break points, stepping, etc.

eCos configuration

  cdl_configuration eCos {
      template    default ;
      package CYGPKG_IO_FILEIO current ;
      package CYGPKG_USTL current ;
      package CYGPKG_COMPRESS_ZLIB current ;
      package CYGPKG_CRC current ;
      package CYGPKG_FS_RAM current ;
      package CYGPKG_POSIX current ;
      package CYGPKG_OBJLOADER current ;
      package CYGPKG_FS_ROM current ;
      package CYGPKG_UITRON current ;
  };
  cdl_option CYGSEM_INFRA_RESET_ON_TEST_EXIT {
      user_value 1
  };
  cdl_component CYGTST_ROMFS_BUILD_TESTS {
      user_value 1
  };
  cdl_component CYGTST_SERVICES_OBJLOADER_BUILD_TESTS {
      user_value 1
  };

The eCos sources http://hg-pub.ecoscentric.com/ecos HG tip (changeset
3094:7595029fc92d) and applied attachment 1587 (bug 1001490).

NOTE: USTL bvt13, bvt17 tests were rejected from the batch run (they
expect a user input on cin) and bvt05 as it does not fit amount of RAM
on the target.

Sergei

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]
  2012-03-02 16:36             ` Alex Schuilenburg
@ 2012-03-03 13:32               ` Ilija Kocho
  2012-03-04  0:10                 ` Alex Schuilenburg
  0 siblings, 1 reply; 76+ messages in thread
From: Ilija Kocho @ 2012-03-03 13:32 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: eCos developers

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
> 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 hope that the testing with STM32 may give us some hint.
I also wander if test with RedBoot from current CVS would help.

Regards

Ilija

>> 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.
> I have added the configuration you sent to our test farm, although
> obviously because the sources are eCosPro, there is no uSTL support
> testing for the Embedded Artists LPC2468-32.
>
> I'll let you know how we get on with the ST STM3210E-EVAL board testing.
>
> Cheers
> -- Alex
> Managing Director/CEO                                eCosCentric Limited
> www.ecoscentric.com             Reg in England and Wales, Reg No 4422071
>
>

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]
  2012-03-03 13:32               ` Ilija Kocho
@ 2012-03-04  0:10                 ` Alex Schuilenburg
  2012-03-04 17:49                   ` Sergei Gavrikov
  2012-03-04 19:37                   ` eCos GNU tools 4.6.2-20120125 ready for testing John Dallaway
  0 siblings, 2 replies; 76+ messages in thread
From: Alex Schuilenburg @ 2012-03-04  0:10 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: Alex Schuilenburg, eCos developers

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

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.


> .
> I hope that the testing with STM32 may give us some hint.

anoncvs eCos for the stm3210e_eval board behaves unfortunately in
exactly the same manner.  tests do not even reach cyg_test_init.  I just
did the same switch to the eCosPro source base and the tests run so far
all passed.


> I also wander if test with RedBoot from current CVS would help.
I spoke to Nick Garnett who said there is a remote possibility that the
anoncvs sources have become incompatible with the eCosPro RedBoot, and
given that anoncvs tests for both selected targets die in the same
manner, I will rebuild RedBoot and give it a go.  I'll need to fetch the
boards from the testfarm though (our testfarm is off-site, in a shed on
a "farm" :-) to do this, or maybe just try a RAM redboot first.  I'll
let you know how I get on.

Hopefully it is something simple and not that eCos in anoncvs for both
boards has been subject to bitrot.

-- Alex

Managing Director/CEO                                eCosCentric Limited
www.ecoscentric.com             Reg in England and Wales, Reg No 4422071



^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]
  2012-03-04  0:10                 ` Alex Schuilenburg
@ 2012-03-04 17:49                   ` Sergei Gavrikov
  2012-03-04 23:08                     ` Alex Schuilenburg
  2012-03-04 19:37                   ` eCos GNU tools 4.6.2-20120125 ready for testing John Dallaway
  1 sibling, 1 reply; 76+ messages in thread
From: Sergei Gavrikov @ 2012-03-04 17:49 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: Ilija Kocho, Alex Schuilenburg, eCos developers

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
> could be a more general issues with the anoncvs code (see below).
> 
> 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.
> 
> 
> > .
> > I hope that the testing with STM32 may give us some hint.
> 
> anoncvs eCos for the stm3210e_eval board behaves unfortunately in
> exactly the same manner.  tests do not even reach cyg_test_init.  I just
> did the same switch to the eCosPro source base and the tests run so far
> all passed.
> 
> 
> > I also wander if test with RedBoot from current CVS would help.
> I spoke to Nick Garnett who said there is a remote possibility that the
> anoncvs sources have become incompatible with the eCosPro RedBoot, and
> given that anoncvs tests for both selected targets die in the same
> manner, I will rebuild RedBoot and give it a go.  I'll need to fetch the
> boards from the testfarm though (our testfarm is off-site, in a shed on
> a "farm" :-) to do this, or maybe just try a RAM redboot first.  I'll
> let you know how I get on.
> 
> Hopefully it is something simple and not that eCos in anoncvs for both
> boards has been subject to bitrot.
> 
> -- Alex
 
Hi Alex

I just wonder, is there

  set cyg_test_is_simulator=0

line in your gdbinit file?

I mean that default gdbinit template (generated by eCos configtool) is

  set height 0
  set debug remote 0
  set remotebaud %b
  target remote %p
  load
  break cyg_test_exit
  rbreak cyg_assert_fail
  break cyg_test_init
  cont
  set cyg_test_is_simulator=0 <-- New GDB will stop here
  cont
  bt 64

and this

  for i in $(find install/tests -type f)
  do
    echo $i
    arm-eabi-nm $i | grep cyg_test_is_simulator
  done

shows that only a very few eCos tests are compiled with GCC 4.6 have
cyg_test_is_simulator variable in .data.

For example,

  % arm-eabi-nm install/tests/hal/common/current/tests/basic | grep simulator
  <no output>

GDB 6.8

  (gdb) set cyg_test_is_simulator=0	<- ?! (no error)
  (gdb) cont
  Continuing.
  PASS:<HAL_xSBIT_INDEX() basic functions>
  PASS:<hal_setjmp()/hal_longjmp() basic functions>
  EXIT:<HAL basic functions test>

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.

Well, it is just a guess, no more that. For default template only these tests
have simulator flag:

  install/tests/infra/current/tests/cxxsupp
  install/tests/infra/current/tests/diag_sprintf1
  install/tests/infra/current/tests/diag_sprintf2
  install/tests/kernel/current/tests/fptest
  install/tests/kernel/current/tests/kill
  install/tests/kernel/current/tests/kclock1
  install/tests/kernel/current/tests/dhrystone
  install/tests/kernel/current/tests/kmutex4
  install/tests/kernel/current/tests/mutex3
  install/tests/kernel/current/tests/kmutex3
  install/tests/kernel/current/tests/stress_threads
  install/tests/kernel/current/tests/clock1
  install/tests/kernel/current/tests/bin_sem2
  install/tests/kernel/current/tests/tm_basic
  install/tests/kernel/current/tests/clockcnv
  install/tests/io/wallclock/current/tests/wallclock
  install/tests/services/memalloc/common/current/tests/malloc4
  install/tests/services/memalloc/common/current/tests/heaptest

And my gdbinit had no

  set cyg_test_is_simulator=0

By this reason it was possible for me to run long GDB batch jobs on my target
without stops.

Sergei

> Managing Director/CEO                                eCosCentric Limited
> www.ecoscentric.com             Reg in England and Wales, Reg No 4422071
> 
> 
> 

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-04  0:10                 ` Alex Schuilenburg
  2012-03-04 17:49                   ` Sergei Gavrikov
@ 2012-03-04 19:37                   ` John Dallaway
  2012-03-04 23:47                     ` Alex Schuilenburg
  2012-03-05  8:30                     ` eCos GNU tools 4.6.2-20120125 ready for testing Tomas Frydrych
  1 sibling, 2 replies; 76+ messages in thread
From: John Dallaway @ 2012-03-04 19:37 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: Ilija Kocho, eCos developers

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

An incompatibility between eCos RAM startup application code and the
eCosPro build of RedBoot for this platform seems more likely.

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

>> I hope that the testing with STM32 may give us some hint.
> 
> anoncvs eCos for the stm3210e_eval board behaves unfortunately in
> exactly the same manner.  tests do not even reach cyg_test_init.  I just
> did the same switch to the eCosPro source base and the tests run so far
> all passed.
> 
>> I also wander if test with RedBoot from current CVS would help.
> 
> I spoke to Nick Garnett who said there is a remote possibility that the
> anoncvs sources have become incompatible with the eCosPro RedBoot,

Certainly some change, either in eCos sources or eCosPro sources, may
have introduced an incompatibility. At present, this seems to be the
most likely explanation for the behaviour you have observed.

> and given that anoncvs tests for both selected targets die in the same
> manner, I will rebuild RedBoot and give it a go.

Great. Thank you. Clearly RedBoot and RAM startup application code must
share a common understanding of memory layout (including the precise
layout of the virtual vector table).

> I'll need to fetch the
> boards from the testfarm though (our testfarm is off-site, in a shed on
> a "farm" :-) to do this, or maybe just try a RAM redboot first.  I'll
> let you know how I get on.
> 
> Hopefully it is something simple and not that eCos in anoncvs for both
> boards has been subject to bitrot.

FYI, I have just built ROM RedBoot and the tm_basic kernel test for
STM3210E-EVAL from latest CVS sources using the new arm-eabi test
release toolchain (4.6.2-20120125). I can confirm that there is no issue
with running this (RAM startup) test via this RedBoot image and hitting
breakpoints at cyg_test_init() and cyg_test_exit(). There are many
people using this board within the eCos community and I believe that
eCos/RedBoot support for STM3210E-EVAL is solid.

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.

John Dallaway

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6]
  2012-03-04 17:49                   ` Sergei Gavrikov
@ 2012-03-04 23:08                     ` Alex Schuilenburg
  0 siblings, 0 replies; 76+ messages in thread
From: Alex Schuilenburg @ 2012-03-04 23:08 UTC (permalink / raw)
  To: Sergei Gavrikov; +Cc: Ilija Kocho, eCos developers

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:
if &cyg_test_is_simulator!=0
set cyg_test_is_simulator=0
end

FWIW, using gdbinit or user-defined command files does not always work
for this exact reason - gdb will stop on the first error.  This is why
we have our own scripts, although you could also use the gui configtool
which uses a simplistic but reasonable approach.

However, dropping "set cyg_test_is_simulator=0" for running tests on
hardware is a good idea since it will be zero as it is in .bss.    You
could try the code segment above as another alternative.

-- Alex

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-04 19:37                   ` eCos GNU tools 4.6.2-20120125 ready for testing John Dallaway
@ 2012-03-04 23:47                     ` Alex Schuilenburg
  2012-03-05  8:00                       ` Sergei Gavrikov
  2012-03-07 11:58                       ` Alex Schuilenburg
  2012-03-05  8:30                     ` eCos GNU tools 4.6.2-20120125 ready for testing Tomas Frydrych
  1 sibling, 2 replies; 76+ messages in thread
From: Alex Schuilenburg @ 2012-03-04 23:47 UTC (permalink / raw)
  To: John Dallaway; +Cc: Ilija Kocho, eCos developers

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
>> 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).
> An incompatibility between eCos RAM startup application code and the
> eCosPro build of RedBoot for this platform seems more likely.

Could be.  I was basing my hypothesis off the fact that the LPC2468-32
was run in the farm as part of the eCos 3.0 public release and the
RedBoot on that board is dated April 2008 so at some point I assumed
anoncvs eCos ran successfully. 

>> 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'll need to fetch the
boards from the testfarm though (our testfarm is off-site, in a shed on
a "farm" :-) to do this, or maybe just try a RAM redboot first.  I'll
let you know how I get on.

Hopefully it is something simple and not that eCos in anoncvs for both
boards has been subject to bitrot.
 

[...]
> FYI, I have just built ROM RedBoot and the tm_basic kernel test for
> STM3210E-EVAL from latest CVS sources using the new arm-eabi test
> release toolchain (4.6.2-20120125). I can confirm that there is no issue
> with running this (RAM startup) test via this RedBoot image and hitting
> breakpoints at cyg_test_init() and cyg_test_exit(). There are many
> people using this board within the eCos community and I believe that
> eCos/RedBoot support for STM3210E-EVAL is solid.

It should be - we contributed it ;-)

This is useful info at least and does point to an incompatibility issue
between the eCos and eCosPro RedBoot.  I will put the RedBoot built from
anoncvs onto both boards and restart...


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

Ooops.  I had forgotten to reload our test client to use the newer gdb
when I reported the first couple of tests had passed.  We also see the
same failure.

-- Alex

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-04 23:47                     ` Alex Schuilenburg
@ 2012-03-05  8:00                       ` Sergei Gavrikov
  2012-03-07 13:51                         ` Sergei Gavrikov
  2012-03-07 11:58                       ` Alex Schuilenburg
  1 sibling, 1 reply; 76+ messages in thread
From: Sergei Gavrikov @ 2012-03-05  8:00 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: John Dallaway, Ilija Kocho, eCos developers

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-04 19:37                   ` eCos GNU tools 4.6.2-20120125 ready for testing John Dallaway
  2012-03-04 23:47                     ` Alex Schuilenburg
@ 2012-03-05  8:30                     ` Tomas Frydrych
  2012-03-05  8:56                       ` Tomas Frydrych
  1 sibling, 1 reply; 76+ messages in thread
From: Tomas Frydrych @ 2012-03-05  8:30 UTC (permalink / raw)
  To: ecos-devel

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-05  8:30                     ` eCos GNU tools 4.6.2-20120125 ready for testing Tomas Frydrych
@ 2012-03-05  8:56                       ` Tomas Frydrych
  2012-03-05  9:50                         ` John Dallaway
  0 siblings, 1 reply; 76+ messages in thread
From: Tomas Frydrych @ 2012-03-05  8:56 UTC (permalink / raw)
  To: ecos-devel

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

> 
> Tomas

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-05  8:56                       ` Tomas Frydrych
@ 2012-03-05  9:50                         ` John Dallaway
  2012-03-05  9:55                           ` Anders Montonen
  2012-03-05 10:16                           ` Ilija Kocho
  0 siblings, 2 replies; 76+ messages in thread
From: John Dallaway @ 2012-03-05  9:50 UTC (permalink / raw)
  To: Tomas Frydrych; +Cc: ecos-devel

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
should add a CDL option to our GDB stub code to accommodate this change.
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.

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-05  9:50                         ` John Dallaway
@ 2012-03-05  9:55                           ` Anders Montonen
  2012-03-05 14:20                             ` John Dallaway
  2012-03-05 10:16                           ` Ilija Kocho
  1 sibling, 1 reply; 76+ messages in thread
From: Anders Montonen @ 2012-03-05  9:55 UTC (permalink / raw)
  To: ecos-devel


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@lists.berlios.de/msg18182.html>

-a

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-05  9:50                         ` John Dallaway
  2012-03-05  9:55                           ` Anders Montonen
@ 2012-03-05 10:16                           ` Ilija Kocho
  2012-03-05 12:56                             ` Tomas Frydrych
  1 sibling, 1 reply; 76+ messages in thread
From: Ilija Kocho @ 2012-03-05 10:16 UTC (permalink / raw)
  To: John Dallaway; +Cc: Tomas Frydrych, ecos-devel

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
> should add a CDL option to our GDB stub code to accommodate this change.
> 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.

Could the reason for this be because Cortex-M(4) uses VFP architecture
rather than FPA?
The FPU used on Cortex-M4 is FPv4-SP-d16
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439c/BEHFGGGE.html

Ilija

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-05 10:16                           ` Ilija Kocho
@ 2012-03-05 12:56                             ` Tomas Frydrych
  0 siblings, 0 replies; 76+ messages in thread
From: Tomas Frydrych @ 2012-03-05 12:56 UTC (permalink / raw)
  To: ecos-devel

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
>> register set for Cortex-M targets in recent GDB. In the longer term, we
>> should add a CDL option to our GDB stub code to accommodate this change.
>> 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.
> 
> Could the reason for this be because Cortex-M(4) uses VFP architecture
> rather than FPA?
> The FPU used on Cortex-M4 is FPv4-SP-d16
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439c/BEHFGGGE.html

I think the original inclusion of the FP registers is to accommodate
earlier version of GDB that expected any arm platform to have FP
registers even though few really did -- I think it will be necessary for
the gdb stubs to have a CDL option to choose which gdb incarnation to
target, I don't think there is any way to do the right thing automatically.

I do not know if gdb 7.3 expects any sort of fp registers on M4, if so
it might be necessary for the definitions in cortexm_stubs.h to be more
finely honed based on the cortex-m variant.

Tomas

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-05  9:55                           ` Anders Montonen
@ 2012-03-05 14:20                             ` John Dallaway
  0 siblings, 0 replies; 76+ messages in thread
From: John Dallaway @ 2012-03-05 14:20 UTC (permalink / raw)
  To: Anders Montonen; +Cc: ecos-devel

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-04 23:47                     ` Alex Schuilenburg
  2012-03-05  8:00                       ` Sergei Gavrikov
@ 2012-03-07 11:58                       ` Alex Schuilenburg
  2012-03-07 13:01                         ` Ilija Kocho
                                           ` (2 more replies)
  1 sibling, 3 replies; 76+ messages in thread
From: Alex Schuilenburg @ 2012-03-07 11:58 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: eCos developers

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 {
    template default ;
    package CYGPKG_USTL current ;
    package CYGPKG_IO_FILEIO current ;
};
EOF
ecosconfig import ustl1.ecm
ecosconfig resolve
ecosconfig tree
...


infra1:
ecosconfig -i new stm3210e_eval
cat > infra1.ecm <<EOF;
cdl_configuration infra1 {
    template    uitron ;
    package -template CYGPKG_UITRON current ;
};

cdl_component CYG_HAL_STARTUP {
    user_value RAM
};

cdl_component CYGPKG_INFRA_DEBUG {
    user_value 1
};
EOF
ecosconfig import infra1.ecm
ecosconfig resolve
ecosconfig tree
...


compile1:
Default build with "-Os"

absent1:
ecosconfig -i new stm3210e_eval

cat > absent1.ecm <<EOF;
cdl_configuration absent1 {
    hardware    stm3210e_eval ;
    template    uitron ;
    package -template CYGPKG_UITRON current ;
};

cdl_component CYG_HAL_STARTUP {
    user_value RAM
};

cdl_option CYGSEM_LIBC_EXIT_CALLS_FFLUSH {
    user_value 0
};

cdl_option CYGFUN_LIBC_TIME_POSIX {
    user_value 0
};

cdl_option CYGIMP_LIBC_TIME_ASCTIME_R_INLINE {
    user_value 0
};

cdl_option CYGIMP_LIBC_TIME_CTIME_R_INLINE {
    user_value 0
};

cdl_option CYGIMP_LIBC_TIME_GMTIME_R_INLINE {
    user_value 0
};

cdl_option CYGIMP_LIBC_TIME_LOCALTIME_R_INLINE {
    user_value 0
};

cdl_option CYGSEM_LIBM_USE_STDERR {
    user_value 0
};
EOF

ecosconfig import absent1.ecm

ecosconfig resolve
ecosconfig tree
...



Cheers
- Alex Schuilenburg

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


^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-07 11:58                       ` Alex Schuilenburg
@ 2012-03-07 13:01                         ` Ilija Kocho
  2012-03-07 13:39                           ` Sergei Gavrikov
  2012-03-07 13:13                         ` John Dallaway
  2012-03-08 17:28                         ` Alex Schuilenburg
  2 siblings, 1 reply; 76+ messages in thread
From: Ilija Kocho @ 2012-03-07 13:01 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: eCos developers

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
> 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 {
>     template default ;
>     package CYGPKG_USTL current ;
>     package CYGPKG_IO_FILEIO current ;
> };
> EOF
> ecosconfig import ustl1.ecm
> ecosconfig resolve
> ecosconfig tree
> ...
>
>
> infra1:
> ecosconfig -i new stm3210e_eval
> cat > infra1.ecm <<EOF;
> cdl_configuration infra1 {
>     template    uitron ;
>     package -template CYGPKG_UITRON current ;
> };
>
> cdl_component CYG_HAL_STARTUP {
>     user_value RAM
> };
>
> cdl_component CYGPKG_INFRA_DEBUG {
>     user_value 1
> };
> EOF
> ecosconfig import infra1.ecm
> ecosconfig resolve
> ecosconfig tree
> ...
>
>
> compile1:
> Default build with "-Os"
>
> absent1:
> ecosconfig -i new stm3210e_eval
>
> cat > absent1.ecm <<EOF;
> cdl_configuration absent1 {
>     hardware    stm3210e_eval ;
>     template    uitron ;
>     package -template CYGPKG_UITRON current ;
> };
>
> cdl_component CYG_HAL_STARTUP {
>     user_value RAM
> };
>
> cdl_option CYGSEM_LIBC_EXIT_CALLS_FFLUSH {
>     user_value 0
> };
>
> cdl_option CYGFUN_LIBC_TIME_POSIX {
>     user_value 0
> };
>
> cdl_option CYGIMP_LIBC_TIME_ASCTIME_R_INLINE {
>     user_value 0
> };
>
> cdl_option CYGIMP_LIBC_TIME_CTIME_R_INLINE {
>     user_value 0
> };
>
> cdl_option CYGIMP_LIBC_TIME_GMTIME_R_INLINE {
>     user_value 0
> };
>
> cdl_option CYGIMP_LIBC_TIME_LOCALTIME_R_INLINE {
>     user_value 0
> };
>
> cdl_option CYGSEM_LIBM_USE_STDERR {
>     user_value 0
> };
> EOF
>
> ecosconfig import absent1.ecm
>
> ecosconfig resolve
> ecosconfig tree
> ...
>
>
>
> Cheers
> - Alex Schuilenburg
>
> 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  **
>
>

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-07 11:58                       ` Alex Schuilenburg
  2012-03-07 13:01                         ` Ilija Kocho
@ 2012-03-07 13:13                         ` John Dallaway
  2012-03-12 16:43                           ` Alex Schuilenburg
  2012-03-08 17:28                         ` Alex Schuilenburg
  2 siblings, 1 reply; 76+ messages in thread
From: John Dallaway @ 2012-03-07 13:13 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: Ilija Kocho, eCos developers

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

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 #2: gdb-tdesc-cortexm-fpa-120307.tar.bz2 --]
[-- Type: application/x-bzip, Size: 1599 bytes --]

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-07 13:01                         ` Ilija Kocho
@ 2012-03-07 13:39                           ` Sergei Gavrikov
  0 siblings, 0 replies; 76+ messages in thread
From: Sergei Gavrikov @ 2012-03-07 13:39 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: Alex Schuilenburg, eCos developers

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.

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

I did not tried '-Os' builds, so, I will try to reproduce those faults
(for comparison) on ARM7 target.

And there is more news for me, that is `testintr' ...

Sergei

> 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
> > 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 {
> >     template default ;
> >     package CYGPKG_USTL current ;
> >     package CYGPKG_IO_FILEIO current ;
> > };
> > EOF
> > ecosconfig import ustl1.ecm
> > ecosconfig resolve
> > ecosconfig tree
> > ...
> >
> >
> > infra1:
> > ecosconfig -i new stm3210e_eval
> > cat > infra1.ecm <<EOF;
> > cdl_configuration infra1 {
> >     template    uitron ;
> >     package -template CYGPKG_UITRON current ;
> > };
> >
> > cdl_component CYG_HAL_STARTUP {
> >     user_value RAM
> > };
> >
> > cdl_component CYGPKG_INFRA_DEBUG {
> >     user_value 1
> > };
> > EOF
> > ecosconfig import infra1.ecm
> > ecosconfig resolve
> > ecosconfig tree
> > ...
> >
> >
> > compile1:
> > Default build with "-Os"
> >
> > absent1:
> > ecosconfig -i new stm3210e_eval
> >
> > cat > absent1.ecm <<EOF;
> > cdl_configuration absent1 {
> >     hardware    stm3210e_eval ;
> >     template    uitron ;
> >     package -template CYGPKG_UITRON current ;
> > };
> >
> > cdl_component CYG_HAL_STARTUP {
> >     user_value RAM
> > };
> >
> > cdl_option CYGSEM_LIBC_EXIT_CALLS_FFLUSH {
> >     user_value 0
> > };
> >
> > cdl_option CYGFUN_LIBC_TIME_POSIX {
> >     user_value 0
> > };
> >
> > cdl_option CYGIMP_LIBC_TIME_ASCTIME_R_INLINE {
> >     user_value 0
> > };
> >
> > cdl_option CYGIMP_LIBC_TIME_CTIME_R_INLINE {
> >     user_value 0
> > };
> >
> > cdl_option CYGIMP_LIBC_TIME_GMTIME_R_INLINE {
> >     user_value 0
> > };
> >
> > cdl_option CYGIMP_LIBC_TIME_LOCALTIME_R_INLINE {
> >     user_value 0
> > };
> >
> > cdl_option CYGSEM_LIBM_USE_STDERR {
> >     user_value 0
> > };
> > EOF
> >
> > ecosconfig import absent1.ecm
> >
> > ecosconfig resolve
> > ecosconfig tree
> > ...
> >
> >
> >
> > Cheers
> > - Alex Schuilenburg
> >
> > 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  **
> >
> >
> 

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-05  8:00                       ` Sergei Gavrikov
@ 2012-03-07 13:51                         ` Sergei Gavrikov
  0 siblings, 0 replies; 76+ messages in thread
From: Sergei Gavrikov @ 2012-03-07 13:51 UTC (permalink / raw)
  To: Sergei Gavrikov
  Cc: Alex Schuilenburg, John Dallaway, Ilija Kocho, eCos developers

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.

Sergei

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-07 11:58                       ` Alex Schuilenburg
  2012-03-07 13:01                         ` Ilija Kocho
  2012-03-07 13:13                         ` John Dallaway
@ 2012-03-08 17:28                         ` Alex Schuilenburg
  2012-03-09  9:39                           ` Ilija Kocho
  2012-03-10 17:16                           ` John Dallaway
  2 siblings, 2 replies; 76+ messages in thread
From: Alex Schuilenburg @ 2012-03-08 17:28 UTC (permalink / raw)
  To: Ilija Kocho, eCos developers

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.

More results later...
-- Alex







^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-08 17:28                         ` Alex Schuilenburg
@ 2012-03-09  9:39                           ` Ilija Kocho
  2012-03-09 17:15                             ` Alex Schuilenburg
  2012-03-10 17:16                           ` John Dallaway
  1 sibling, 1 reply; 76+ messages in thread
From: Ilija Kocho @ 2012-03-09  9:39 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: eCos developers

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
> 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.
>
> More results later...
> -- Alex
>
>
>
>
>
>
>

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-09  9:39                           ` Ilija Kocho
@ 2012-03-09 17:15                             ` Alex Schuilenburg
  0 siblings, 0 replies; 76+ messages in thread
From: Alex Schuilenburg @ 2012-03-09 17:15 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: eCos developers

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 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | atan              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | atan2             | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | atan2             | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | atexit            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | atexit            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | atoi              | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | atoi              | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | atol              | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | atol              | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | basic             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | basic             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | bin_sem0          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | bin_sem0          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | bin_sem1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | bin_sem2          | Pass             |    3 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | bin_sem2          | ActiveTimeout    |  720 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | bin_sem3          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | bin_sem3          | ActiveTimeout    |  720 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | bsearch           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | bsearch           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | cache             | NotApplicable    |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | cache             | NotApplicable    |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | ceil              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | ceil              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | clock             | Pass             |    3 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | clock             | Fail             |    6 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | clock0            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | clock0            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | clock1            | Pass             |    4 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | clock1            | ActiveTimeout    |  721 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | clockcnv          | Pass             |   16 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | clockcnv          | Pass             |   18 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | clocktruth        | Pass             |   47 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | cnt_sem0          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | cnt_sem1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | cnt_sem1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | context           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | context           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | cos               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | cos               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | cosh              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | cosh              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | ctime             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | ctime             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | ctype             | Pass             |    4 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | ctype             | Pass             |    4 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | cxxsupp           | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | dhrystone         | Pass             |   25 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | dhrystone         | Pass             |   27 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | diag_sprintf1     | Pass             |    3 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | diag_sprintf2     | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | div               | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | div               | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | dlmalloc1         | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | dlmalloc1         | ActiveTimeout    |  722 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | dlmalloc2         | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | dlmalloc2         | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | except1           | ExecutionTimeout |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | except1           | ExecutionTimeout |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | exp               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | exp               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | fabs              | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | fabs              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | flag0             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | flag0             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | flag1             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | floor             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | floor             | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | fmod              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | fmod              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | fptest            | Pass             |   39 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | frexp             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | frexp             | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | getenv            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | getenv            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | gmtime            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | gmtime            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | heaptest          | ActiveTimeout    |  727 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | heaptest          | ActiveTimeout    |  726 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | i18nmb            | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | i18nmb            | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | i2c_eeprom        | Pass             |   11 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | i2c_eeprom        | ActiveTimeout    |  721 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | intr0 - kernel    | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | intr0 - kernel    | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kalarm0           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kalarm0           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kcache1           | NotApplicable    |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kcache1           | NotApplicable    |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kcache2           | NotApplicable    |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kcache2           | NotApplicable    |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kclock0           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kclock0           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kclock1           | Pass             |    4 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kclock1           | ActiveTimeout    |  723 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kexcept1          | ExecutionTimeout |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kexcept1          | ExecutionTimeout |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kflag0            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kflag0            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kflag1            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kflag1            | ActiveTimeout    |  721 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kill              | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kill              | ActiveTimeout    |  723 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kintr0            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kintr0            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | klock             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | klock             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kmbox1            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kmbox1            | ActiveTimeout    |  723 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kmemfix1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kmemfix1          | ActiveTimeout    |  722 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kmemvar1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kmemvar1          | ActiveTimeout    |  722 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kmutex0           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kmutex0           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kmutex1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kmutex1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kmutex3           | Pass             |   31 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kmutex4           | Pass             |   46 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | kmutex4           | ActiveTimeout    |  721 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | ksched1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | ksched1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | ksem0             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | ksem0             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | ksem1             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | ksem1             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kthread0          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | kthread1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | labs              | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | labs              | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | ldexp             | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | ldexp             | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | ldiv              | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | ldiv              | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | localtime         | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | localtime         | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | log               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | log               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | log10             | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | log10             | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | malloc1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | malloc1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | malloc2           | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | malloc2           | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | malloc3           | ActiveTimeout    |  728 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | malloc3           | ActiveTimeout    |  726 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | malloc4           | ActiveTimeout    |  726 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | malloc4           | ActiveTimeout    |  730 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | mbox1             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | mbox1             | ActiveTimeout    |  721 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memchr            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memchr            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memcmp1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memcmp1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memcmp2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memcmp2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memcpy1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memcpy1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memcpy2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memcpy2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memfix1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memfix1           | ActiveTimeout    |  722 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memfix2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memfix2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memmove1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memmove1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memmove2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memmove2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memset            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memset            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memvar1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memvar1           | ActiveTimeout    |  723 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | memvar2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | memvar2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | mktime            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | mktime            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | modf              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | modf              | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | mqueue1           | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | mqueue1           | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | mutex0            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | mutex0            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | mutex1            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | mutex1            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | mutex2            | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | mutex2            | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | mutex3            | Pass             |   31 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | mutex3            | ActiveTimeout    |  722 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | pow               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | pow               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | qsort             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | qsort             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | rand1             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | rand1             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | rand2             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | rand2             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | rand3             | Pass             |    4 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | rand3             | Pass             |    7 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | rand4             | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | rand4             | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | realloc           | ActiveTimeout    |  726 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | realloc           | ActiveTimeout    |  725 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | release           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | release           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | sched1            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | sched1            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | sepmeta1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | sepmeta1          | ActiveTimeout    |  722 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | sepmeta2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | sepmeta2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | setjmp            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | setjmp            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | setlocale         | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | setlocale         | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | signal1 - signals | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | signal1 - signals | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | sin               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | sin               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | sinh              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | sinh              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | snprintf          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | snprintf          | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | sprintf1          | Pass             |    7 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | sprintf1          | Pass             |    7 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | sprintf2          | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | sprintf2          | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | sqrt              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | sqrt              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | srand             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | srand             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | sscanf            | Pass             |    3 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | sscanf            | Pass             |    3 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | stdiooutput       | Pass             |    4 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | stdiooutput       | Pass             |    4 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strcat1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strcat1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strcat2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strcat2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strchr            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strchr            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strcmp1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strcmp1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strcmp2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strcmp2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strcoll1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strcoll1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strcoll2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strcoll2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strcpy1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strcpy1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strcpy2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strcpy2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strcspn           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strcspn           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | stress_threads    | Pass             |   25 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | stress_threads    | ActiveTimeout    |  721 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strftime          | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strftime          | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strlen            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strlen            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strncat1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strncat1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strncat2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strncat2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strncpy1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strncpy1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strncpy2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strncpy2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strnlen           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strnlen           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strpbrk           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strpbrk           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strptime          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strptime          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strrchr           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strrchr           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strspn            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strspn            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strstr            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strstr            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strtok            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strtok            | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strtol            | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strtol            | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strtoul           | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strtoul           | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strxfrm1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strxfrm1          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | strxfrm2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | strxfrm2          | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | sync2             | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | sync2             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | sync3             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | sync3             | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | tan               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | tan               | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | tanh              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | tanh              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | thread0           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | thread0           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | thread1           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | thread1           | ActiveTimeout    |  724 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | thread2           | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | thread2           | ActiveTimeout    |  722 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | thread_gdb        | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | thread_gdb        | Pass             |    1 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | time              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | time              | Pass             |    2 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | timeslice         | Pass             |   28 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | timeslice         | ActiveTimeout    |  722 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | timeslice2        | Pass             |   28 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | timeslice2        | ActiveTimeout    |  720 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | tm_basic          | Pass             |   35 |
| ecos-anoncvs-arm-ea_lpc2468_32-thumb | default | tm_basic          | ActiveTimeout    |  725 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | wallclock         | Pass             |   23 |
| ecos-anoncvs-arm-ea_lpc2468_32       | default | wallclock2        | Pass             |    1 |
+--------------------------------------+---------+-------------------+------------------+------+


Yes, this is generated from a mysql database :-)

The two types of timeouts, "active" and "exec", are timeouts for output
to be seen from the tests, and maximum execution time permitted
respectively.  These are 720 and 900 seconds respectively for this
platform.  The time is the total time it took for the test to be run in
the test farm (excluding download time) which I have included so you can
see we are being more than generous for the thumb tests.  Missing tests
just have not been run yet.  I have included all passes so you can see
which failures are thumb-only.

And here is a total list of all the failures for the stm3210e_eval board
(4191 tests run so far):

+--------------------------------+----------+-----------------+---------------+------+
| build                          | perm     | test            | result        | time |
+--------------------------------+----------+-----------------+---------------+------+
| ecos-anoncvs-arm-stm3210e_eval | absent1  | testintr        | Fail          |    9 |
| ecos-anoncvs-arm-stm3210e_eval | absent3  | testintr        | Fail          |    3 |
| ecos-anoncvs-arm-stm3210e_eval | bsdnet2  | except1         | Fail          |   12 |
| ecos-anoncvs-arm-stm3210e_eval | bsdnet2  | kexcept1        | Fail          |    5 |
| ecos-anoncvs-arm-stm3210e_eval | bsdnet2  | signal2 - posix | Fail          |    8 |
| ecos-anoncvs-arm-stm3210e_eval | bsdnet2  | timers - var    | NotFinished   |   33 |
| ecos-anoncvs-arm-stm3210e_eval | bsdnet3  | timers - var    | NotFinished   |   27 |
| ecos-anoncvs-arm-stm3210e_eval | compile1 | testintr        | Fail          |    8 |
| ecos-anoncvs-arm-stm3210e_eval | infra1   | except1         | Fail          |    8 |
| ecos-anoncvs-arm-stm3210e_eval | infra1   | kexcept1        | Fail          |    7 |
| ecos-anoncvs-arm-stm3210e_eval | infra1   | testintr        | Fail          |   10 |
| ecos-anoncvs-arm-stm3210e_eval | infra2   | except1         | Fail          |    8 |
| ecos-anoncvs-arm-stm3210e_eval | infra2   | kexcept1        | Fail          |    8 |
| ecos-anoncvs-arm-stm3210e_eval | infra2   | testintr        | Fail          |    9 |
| ecos-anoncvs-arm-stm3210e_eval | libc1    | testintr        | Fail          |    6 |
| ecos-anoncvs-arm-stm3210e_eval | libc2    | testintr        | Fail          |    8 |
| ecos-anoncvs-arm-stm3210e_eval | libm1    | testintr        | Fail          |   12 |
| ecos-anoncvs-arm-stm3210e_eval | libm2    | testintr        | Fail          |    4 |
| ecos-anoncvs-arm-stm3210e_eval | posix1   | except1         | Fail          |    7 |
| ecos-anoncvs-arm-stm3210e_eval | posix1   | kexcept1        | Fail          |    6 |
| ecos-anoncvs-arm-stm3210e_eval | posix1   | signal2 - posix | Fail          |   10 |
| ecos-anoncvs-arm-stm3210e_eval | posix1   | timers - var    | NotFinished   |   66 |
| ecos-anoncvs-arm-stm3210e_eval | posix2   | except1         | Fail          |   10 |
| ecos-anoncvs-arm-stm3210e_eval | posix2   | kexcept1        | Fail          |    3 |
| ecos-anoncvs-arm-stm3210e_eval | posix2   | signal2 - posix | Fail          |    4 |
| ecos-anoncvs-arm-stm3210e_eval | uitron1  | testintr        | Fail          |    9 |
| ecos-anoncvs-arm-stm3210e_eval | uitron2  | testintr        | Fail          |    4 |
| ecos-anoncvs-arm-stm3210e_eval | ustl1    | bvt05           | NotFinished   |   23 |
| ecos-anoncvs-arm-stm3210e_eval | ustl1    | bvt13           | ActiveTimeout |  313 |
| ecos-anoncvs-arm-stm3210e_eval | ustl1    | bvt17           | ActiveTimeout |  310 |
| ecos-anoncvs-arm-stm3210e_eval | ustl1    | sprintf2        | Fail          |   10 |
+--------------------------------+----------+-----------------+---------------+------+


In this case all the NotFinished results terminate due to:

*Program received signal SIGTRAP, Trace/breakpoint trap.*
timers_test (data=<value optimized out>)
    at /home/farm/ecos/ecos-anoncvs/2012-03-01_00.00.00_UTC/packages/hal/cortexm/stm32/var/current/tests/timers.c:265
265	    while( loops-- )
/(gdb)/* bt*
#0  timers_test (data=<value optimized out>)
    at /home/farm/ecos/ecos-anoncvs/2012-03-01_00.00.00_UTC/packages/hal/cortexm/stm32/var/current/tests/timers.c:265
#1  0x6800c182 in Cyg_HardwareThread::thread_entry (thread=0x68031dd0)
    at /home/farm/ecos/ecos-anoncvs/2012-03-01_00.00.00_UTC/packages/kernel/current/src/common/thread.cxx:94
/(gdb)/* quit*


Unfortunately I don't have the time at the moment to export
non-propritary html versions of these result but I will see what I can
do to put up an hourly cron on one of our servers to generate text/plain
result summaries for you.

Please let me know if you need any more info.

Enjoy the weekend.
-- Alex


^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-08 17:28                         ` Alex Schuilenburg
  2012-03-09  9:39                           ` Ilija Kocho
@ 2012-03-10 17:16                           ` John Dallaway
  2012-03-12 16:12                             ` Alex Schuilenburg
  1 sibling, 1 reply; 76+ messages in thread
From: John Dallaway @ 2012-03-10 17:16 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: Ilija Kocho, eCos developers, Uwe Kindler

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-10 17:16                           ` John Dallaway
@ 2012-03-12 16:12                             ` Alex Schuilenburg
  2012-03-13 13:31                               ` Alex Schuilenburg
  0 siblings, 1 reply; 76+ messages in thread
From: Alex Schuilenburg @ 2012-03-12 16:12 UTC (permalink / raw)
  To: John Dallaway; +Cc: eCos developers

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
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.
Previously, when it came up it complained:

+
LPC2XXX_ETH: Initialising 0xFFE00000
LPC2XXX_ETH - Warning! ESA unknown
LPC2XXX_ETH: 12:34:56:78:9a:bc
No network interfaces found

RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version UNKNOWN - built 18:10:14, Mar  7 2012


Now it gives no such complaints. It could be down to the boards though
because we know one of these boards was a bit fragile when run in the
farm last time, although we think it was for resetting only and we
thought it was the one I have here that was fragile. 

Alternatively, unless there is an undocumented ethernet option for
configuring ethernet support for RedBoot for this board, ethernet
support could have suffered bitrot since the extension for LPC17xx parts
and this *may* be affecting the test results. The ethernet is connected
to the board in the farm.

We will hopefully swap the boards over tomorrow in the farm so some of
these failures will start passing.  The timeouts are killing progress. I
will restart the tests in the farm which will clean up tests like
"heaptest" which appear effected by either the "faulty ethernet RedBoot"
or the board and will re-run "heaptest" once I have replaced RedBoot
when I get this board back to confirm which is at fault (board or RedBoot).

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


^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-07 13:13                         ` John Dallaway
@ 2012-03-12 16:43                           ` Alex Schuilenburg
  2012-03-16 15:05                             ` Alex Schuilenburg
  0 siblings, 1 reply; 76+ messages in thread
From: Alex Schuilenburg @ 2012-03-12 16:43 UTC (permalink / raw)
  To: John Dallaway; +Cc: eCos developers

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?

If so I would prefer rather to wait until the newer toolchain is
provided since the tests would need to be re-run.  The farm has just hit
the 9000 test mark for this platform with no new additional test
failures, other than the same tests already reported in different
configurations.

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



^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-12 16:12                             ` Alex Schuilenburg
@ 2012-03-13 13:31                               ` Alex Schuilenburg
  2012-03-13 14:16                                 ` Ilija Kocho
  0 siblings, 1 reply; 76+ messages in thread
From: Alex Schuilenburg @ 2012-03-13 13:31 UTC (permalink / raw)
  To: John Dallaway; +Cc: eCos developers

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  *



^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-13 13:31                               ` Alex Schuilenburg
@ 2012-03-13 14:16                                 ` Ilija Kocho
  2012-03-13 17:47                                   ` Sergei Gavrikov
  2012-03-18 19:10                                   ` eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing] Ilija Kocho
  0 siblings, 2 replies; 76+ messages in thread
From: Ilija Kocho @ 2012-03-13 14:16 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: ecos-devel, John Dallaway

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-13 14:16                                 ` Ilija Kocho
@ 2012-03-13 17:47                                   ` Sergei Gavrikov
  2012-03-15  8:50                                     ` John Dallaway
  2012-03-18 19:10                                   ` eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing] Ilija Kocho
  1 sibling, 1 reply; 76+ messages in thread
From: Sergei Gavrikov @ 2012-03-13 17:47 UTC (permalink / raw)
  To: Ilija Kocho; +Cc: Alex Schuilenburg, ecos-devel, John Dallaway

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

  /tmp/cceuQCd7.s: Assembler messages:
  /tmp/cceuQCd7.s:834: Warning: value stored for r3 is UNKNOWN

disassemble output with objdump:

  /tmp/t/net/bsd_tcpip/current/src/sys/netinet/net_bsd_tcpip_ip_icmp.o:
     6:    c30c          stmia    r3!, {r2, r3}

*BUT*, IMHO, this is not issue for this report:
> Ref: http://sourceware.org/ml/ecos-devel/2012-03/msg00024.html

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.

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.

Sergei

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-13 17:47                                   ` Sergei Gavrikov
@ 2012-03-15  8:50                                     ` John Dallaway
  2012-03-17 14:50                                       ` Sergei Gavrikov
  2012-03-17 16:44                                       ` Stanislav Meduna
  0 siblings, 2 replies; 76+ messages in thread
From: John Dallaway @ 2012-03-15  8:50 UTC (permalink / raw)
  To: Sergei Gavrikov; +Cc: ecos-devel

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.

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

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-12 16:43                           ` Alex Schuilenburg
@ 2012-03-16 15:05                             ` Alex Schuilenburg
  0 siblings, 0 replies; 76+ messages in thread
From: Alex Schuilenburg @ 2012-03-16 15:05 UTC (permalink / raw)
  To: eCos developers

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
  signal2 - posix   | bsdnet11, bsdnet2, bsdnet5, posix1, posix2, posix3
  signal2 - signals | libc10
  sprintf2          | ustl1
  testintr          | absent1, absent3, combo11, combo21, combo23, 
                      compile1, compile3, compile4, compile5, compile6,
                      infra1, infra2, infra3, infra4, kernel10, kernel11,
                      kernel3, kernel6, kernel9, libc1, libc10, libc2,
                      libc3, libc4, libc6, libc7, libc8, libc9, libm1,
                      libm2, libm3, libm4, libm5, uitron1, uitron2, 
                      uitron5, uitron6, uitron7
  timers - var      | bsdnet11, bsdnet2, bsdnet3, bsdnet5, bsdnet6, posix1



Just waiting on the new toolchains to start the next batch ...

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




^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-15  8:50                                     ` John Dallaway
@ 2012-03-17 14:50                                       ` Sergei Gavrikov
  2012-03-17 20:58                                         ` John Dallaway
  2012-03-17 16:44                                       ` Stanislav Meduna
  1 sibling, 1 reply; 76+ messages in thread
From: Sergei Gavrikov @ 2012-03-17 14:50 UTC (permalink / raw)
  To: John Dallaway; +Cc: eCos Developers

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

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

It seems to me you are right, I will try to investigate. Thank you for
feedback.

Sergei

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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-15  8:50                                     ` John Dallaway
  2012-03-17 14:50                                       ` Sergei Gavrikov
@ 2012-03-17 16:44                                       ` Stanislav Meduna
  1 sibling, 0 replies; 76+ messages in thread
From: Stanislav Meduna @ 2012-03-17 16:44 UTC (permalink / raw)
  To: ecos-devel

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.

Looks more probable to me.

Regards
-- 
                                           Stano

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.2-20120125 ready for testing
  2012-03-17 14:50                                       ` Sergei Gavrikov
@ 2012-03-17 20:58                                         ` John Dallaway
  0 siblings, 0 replies; 76+ messages in thread
From: John Dallaway @ 2012-03-17 20:58 UTC (permalink / raw)
  To: Sergei Gavrikov; +Cc: eCos Developers

Hi Sergei

On 17 Mar 2012, at 14:50, Sergei Gavrikov <sergei.gavrikov@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

^ permalink raw reply	[flat|nested] 76+ messages in thread

* eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing]
  2012-03-13 14:16                                 ` Ilija Kocho
  2012-03-13 17:47                                   ` Sergei Gavrikov
@ 2012-03-18 19:10                                   ` Ilija Kocho
  2012-04-04 12:57                                     ` Lambrecht Jürgen
  1 sibling, 1 reply; 76+ messages in thread
From: Ilija Kocho @ 2012-03-18 19:10 UTC (permalink / raw)
  To: Alex Schuilenburg; +Cc: ecos-devel, John Dallaway, Jonathan Larmour

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


^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing]
  2012-03-18 19:10                                   ` eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing] Ilija Kocho
@ 2012-04-04 12:57                                     ` Lambrecht Jürgen
  2012-04-04 13:18                                       ` Ilija Kocho
  0 siblings, 1 reply; 76+ messages in thread
From: Lambrecht Jürgen @ 2012-04-04 12:57 UTC (permalink / raw)
  To: Ilija Kocho
  Cc: Alex Schuilenburg, ecos-devel, John Dallaway, Jonathan Larmour

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..
- pointer-sign
- packed attribute (chars are byte aligned by default, so they are 
"naturally packed 
<http://www.mail-archive.com/lwip-users@nongnu.org/msg02757.html>". So 
don't try to pack chars)
- '#ifdef ... #elif' cannot be mixed any more ('#ifdef ... #elif 
defined' instead)
Finally I gave up (for this test) using -Werror because some customer 
code we use is too badly written (I will wait for their update).

But aside from those warnings, it builds fine, and also runs fine on our 
AT91 ARM9 processor.
No issues so far. Do you  know something to watch out for?

Next step is to build the same code version with the old compiler, and 
see with the eCos CPU monitor if there is any difference.

Kind regards,
Jürgen

-- 
Jürgen Lambrecht
R&D Associate
Tel: +32 (0)51 303045    Fax: +32 (0)51 310670
http://www.televic-rail.com
Televic Rail NV - Leo Bekaertlaan 1 - 8870 Izegem - Belgium
Company number 0825.539.581 - RPR Kortrijk

^ permalink raw reply	[flat|nested] 76+ messages in thread

* Re: eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing]
  2012-04-04 12:57                                     ` Lambrecht Jürgen
@ 2012-04-04 13:18                                       ` Ilija Kocho
  2012-05-31  8:42                                         ` eCos GNU tools 4.6.3-20120315 and link time optimization Bernard Fouché
  0 siblings, 1 reply; 76+ messages in thread
From: Ilija Kocho @ 2012-04-04 13:18 UTC (permalink / raw)
  To: Lambrecht Jürgen
  Cc: Alex Schuilenburg, ecos-devel, John Dallaway, Jonathan Larmour

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.
>
> 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..
> - pointer-sign
> - packed attribute (chars are byte aligned by default, so they are 
> "naturally packed 
> <http://www.mail-archive.com/lwip-users@nongnu.org/msg02757.html>". So 
> don't try to pack chars)
> - '#ifdef ... #elif' cannot be mixed any more ('#ifdef ... #elif 
> defined' instead)
> Finally I gave up (for this test) using -Werror because some customer 
> code we use is too badly written (I will wait for their update).
>
> But aside from those warnings, it builds fine, and also runs fine on our 
> AT91 ARM9 processor.
> No issues so far. Do you  know something to watch out for?
>
> Next step is to build the same code version with the old compiler, and 
> see with the eCos CPU monitor if there is any difference.
>
> Kind regards,
> Jürgen
>

^ permalink raw reply	[flat|nested] 76+ messages in thread

* eCos GNU tools 4.6.3-20120315 and link time optimization
  2012-04-04 13:18                                       ` Ilija Kocho
@ 2012-05-31  8:42                                         ` Bernard Fouché
  0 siblings, 0 replies; 76+ messages in thread
From: Bernard Fouché @ 2012-05-31  8:42 UTC (permalink / raw)
  To: ecos-devel

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


^ permalink raw reply	[flat|nested] 76+ messages in thread

end of thread, other threads:[~2012-05-31  8:42 UTC | newest]

Thread overview: 76+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-13 17:01 Gnutools: consideration for upgrade to GCC 4.6 Ilija Kocho
2012-01-13 18:54 ` Bernard Fouché
2012-01-13 19:39   ` Ilija Kocho
2012-01-13 19:09 ` Frank Pagliughi
2012-01-13 19:45   ` Ilija Kocho
2012-01-14 10:22 ` John Dallaway
2012-01-14 16:02   ` Sergei Gavrikov
2012-01-15 17:36     ` Grant Edwards
2012-01-15 18:42       ` Sergei Gavrikov
2012-01-15 21:39         ` Stanislav Meduna
2012-01-23  1:01           ` Jonathan Larmour
2012-01-15 22:21         ` Ilija Kocho
2012-01-15 22:21         ` Ilija Kocho
2012-01-23  1:07           ` Jonathan Larmour
2012-01-16 15:20         ` Grant Edwards
2012-01-16 20:43           ` Sergei Gavrikov
2012-01-16 21:11             ` Sergei Gavrikov
2012-01-17  9:58               ` Bernard Fouché
2012-01-17 10:38                 ` Paul Beskeen
2012-01-17 12:28                   ` Sergei Gavrikov
2012-01-23  0:59     ` Jonathan Larmour
2012-01-14 16:25   ` Ilija Kocho
2012-01-23  1:13     ` Jonathan Larmour
2012-01-23 18:40       ` Ilija Kocho
2012-01-23 19:29         ` Jonathan Larmour
2012-01-25 12:30         ` Alex Schuilenburg
2012-01-25 20:59           ` Ilija Kocho
2012-01-26 13:36             ` Alex Schuilenburg
2012-01-26 20:18               ` Ilija Kocho
2012-02-13 22:02           ` eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] Ilija Kocho
2012-02-20 16:00             ` Alex Schuilenburg
2012-02-20 20:45               ` Ilija Kocho
2012-03-02 16:36             ` Alex Schuilenburg
2012-03-03 13:32               ` Ilija Kocho
2012-03-04  0:10                 ` Alex Schuilenburg
2012-03-04 17:49                   ` Sergei Gavrikov
2012-03-04 23:08                     ` Alex Schuilenburg
2012-03-04 19:37                   ` eCos GNU tools 4.6.2-20120125 ready for testing John Dallaway
2012-03-04 23:47                     ` Alex Schuilenburg
2012-03-05  8:00                       ` Sergei Gavrikov
2012-03-07 13:51                         ` Sergei Gavrikov
2012-03-07 11:58                       ` Alex Schuilenburg
2012-03-07 13:01                         ` Ilija Kocho
2012-03-07 13:39                           ` Sergei Gavrikov
2012-03-07 13:13                         ` John Dallaway
2012-03-12 16:43                           ` Alex Schuilenburg
2012-03-16 15:05                             ` Alex Schuilenburg
2012-03-08 17:28                         ` Alex Schuilenburg
2012-03-09  9:39                           ` Ilija Kocho
2012-03-09 17:15                             ` Alex Schuilenburg
2012-03-10 17:16                           ` John Dallaway
2012-03-12 16:12                             ` Alex Schuilenburg
2012-03-13 13:31                               ` Alex Schuilenburg
2012-03-13 14:16                                 ` Ilija Kocho
2012-03-13 17:47                                   ` Sergei Gavrikov
2012-03-15  8:50                                     ` John Dallaway
2012-03-17 14:50                                       ` Sergei Gavrikov
2012-03-17 20:58                                         ` John Dallaway
2012-03-17 16:44                                       ` Stanislav Meduna
2012-03-18 19:10                                   ` eCos GNU tools 4.6.3-20120315 [Was Re: eCos GNU tools 4.6.2-20120125 ready for testing] Ilija Kocho
2012-04-04 12:57                                     ` Lambrecht Jürgen
2012-04-04 13:18                                       ` Ilija Kocho
2012-05-31  8:42                                         ` eCos GNU tools 4.6.3-20120315 and link time optimization Bernard Fouché
2012-03-05  8:30                     ` eCos GNU tools 4.6.2-20120125 ready for testing Tomas Frydrych
2012-03-05  8:56                       ` Tomas Frydrych
2012-03-05  9:50                         ` John Dallaway
2012-03-05  9:55                           ` Anders Montonen
2012-03-05 14:20                             ` John Dallaway
2012-03-05 10:16                           ` Ilija Kocho
2012-03-05 12:56                             ` Tomas Frydrych
2012-03-03 12:58             ` eCos GNU tools 4.6.2-20120125 ready for testing [Was Re: Gnutools: consideration for upgrade to GCC 4.6] Sergei Gavrikov
2012-01-17  9:37 ` Gnutools: consideration for upgrade to GCC 4.6 Tomas Frydrych
2012-01-17 16:10   ` Stanislav Meduna
2012-01-17 16:25     ` Tomas Frydrych
2012-01-17 16:45     ` Ilija Kocho
2012-01-20 14:42       ` Frank Pagliughi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).