* 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 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 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 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 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 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 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 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-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-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-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-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: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-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 [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 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 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-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-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 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-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: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: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-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-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-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-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
* 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
* 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
* 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: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-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 [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: 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-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
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).