* eCos 3.0 beta 1 remaining issues @ 2009-03-20 11:31 John Dallaway 2009-03-25 11:01 ` John Dallaway 0 siblings, 1 reply; 5+ messages in thread From: John Dallaway @ 2009-03-20 11:31 UTC (permalink / raw) To: eCos Maintainers eCos maintainers There are a few issues raised against eCos 3.0 beta 1 which are still open: http://bugs.ecos.sourceware.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=eCos&version=3.0beta1&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= This is not a large list and I would like to encourage you all to play a part in the last push so we can make the final release by the end of March as intended. Taking each in turn: > 1000717 lwIP TCP/IP drops incoming IP packets on SLIP interface > 1000719 lwip_ppp tests build fails when CYGDBG_LWIP_DEBUG turned on Can someone step up to look at the above lwIP issues please? Sergei has provided a patch for one of them. Jifl would be the maintainer with most experience of lwIP but his availability is limited at present. > 1000693 flash.c assertion failure Andrew, can you confirm whether you are able to address 1000693 for eCos 3.0 or whether we should push it out to be fixed later please? > 1000688 RedBoot GPL message Jifl, you were intending to tackle 1000688 but it could be addressed by someone else if necessary. It's probably better for you to focus on the Thumb compilation issue (1000701). Please do confirm either way whether you would like someone else to take 1000688. > 1000689 ompat/posix/current/tests/signal1 hangs > 1000690 /home/lunn/eCos/work/install/tests/compat/posix/current/tests/signal3 runs forever POSIX compatibility is important for eCos so we really do need to determine whether the above POSIX test failures reflect a genuine issue with the POSIX compatibility layer. These could be tackled by anyone with experience of POSIX. Please do volunteer. > 1000701 Error building vectors.S for Thumb on AT91 targets Jifl has already started looking at 1000701. > 1000713 RedBoot CDL option hierarchy 1000713 is definitely non-blocking. > 1000723 Building eCos C library for synthetic target fails with gcc-3.2 Does anyone care about the synthetic target with very old toolchains? Please shout now if you think 1000723 is important. > 1000685 isoinfra limits.h breaks with gcc 4.3.3/synth Andrew has a fix for 1000685. > 1000707 Multiple is_substr() goals for one CDL item 1000707 will not be addressed in the eCos 3.0 timeframe. > 1000716 Error launching GDB to run eCos tests I am looking at 1000716. > 1000697 ConfigTool: Reset board dialog 1000697 is definitely non-blocking. Thanks, again, for your support... John Dallaway ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: eCos 3.0 beta 1 remaining issues 2009-03-20 11:31 eCos 3.0 beta 1 remaining issues John Dallaway @ 2009-03-25 11:01 ` John Dallaway 2009-03-25 12:22 ` Bart Veer 0 siblings, 1 reply; 5+ messages in thread From: John Dallaway @ 2009-03-25 11:01 UTC (permalink / raw) To: eCos Maintainers [-- Attachment #1: Type: text/plain, Size: 1579 bytes --] eCos maintainers I think the eCos 3.0 branch is now good for a final release. Thank you to all those who have helped in resolving the last few Bugzilla issues. I have appended notes on the action taken. I have also attached a draft version of the release notes. If you have any comments or concerns, please raise them by the end of Thursday 2009-03-25. I will then proceed with generating the final release. John Dallaway -- cut here -- >> 1000717 lwIP TCP/IP drops incoming IP packets on SLIP interface Patch applied >> 1000719 lwip_ppp tests build fails when CYGDBG_LWIP_DEBUG turned on Proposed change seems too invasive at this late stage - documented in release notes >> 1000693 flash.c assertion failure > > Andrew, can you confirm whether you are able to address 1000693 for eCos > 3.0 or whether we should push it out to be fixed later please? Andrew thinks this should be pushed out >> 1000688 RedBoot GPL message I have checked in Sergei's patch >> 1000689 ompat/posix/current/tests/signal1 hangs >> 1000690 /home/lunn/eCos/work/install/tests/compat/posix/current/tests/signal3 runs forever I have backed out the change which caused these issues >> 1000701 Error building vectors.S for Thumb on AT91 targets Fixed by using LDR instructions instead of MOV >> 1000723 Building eCos C library for synthetic target fails with gcc-3.2 Added to release notes >> 1000685 isoinfra limits.h breaks with gcc 4.3.3/synth Andrew has checked in his fix >> 1000716 Error launching GDB to run eCos tests No obvious cause - added to release notes [-- Attachment #2: README-draft-090325.txt --] [-- Type: text/plain, Size: 5144 bytes --] [ Pre-release version 2009-03-25 - NOT FOR DISTRIBUTION ] eCos - the Embedded Configurable Operating System - release 3.0 README ====================================================================== March 2009 Welcome to the eCos 3.0 public release. This README contains a list of known problems with the eCos 3.0 release. Please check for further issues by searching the Bugzilla database for product "eCos" version "3.0": http://bugs.ecos.sourceware.org/query.cgi If you discover new bugs with this release please report them using Bugzilla: http://bugs.ecos.sourceware.org/enter_bug.cgi ------------------------------------------------------------------------------ System Requirements ------------------- This release has been tested against Microsoft Windows 2000, Windows XP, Windows Vista and multiple x86 Linux distributions. Microsoft Windows 95, Windows 98 and Windows ME are not supported. The Linux-hosted eCos development tools require libstdc++ v3 (/usr/lib/libstdc++.so.5). Users of Linux distributions which provide a more recent libstdc++ may need to install a libstdc++ v3 compatibility package. Installation of the compatibility package may be achieved as follows: Fedora: yum install compat-libstdc++-33 openSUSE: zypper install compat-libstdc++ Ubuntu: apt-get install libstdc++5 The Linux-hosted eCos Configuration Tool also requires the GTK+ toolkit version 2.0 or later. The Microsoft Windows-hosted eCos development tools require a recent installation of the Cygwin compatibility layer and associated command-line tools. The Cygwin setup program (installer) may be downloaded at: http://www.cygwin.com An installation of these tools dating from September 2008 or later is recommended. In addition to the packages provided within the "Base" category of the Cygwin installer, the following packages must be installed for correct operation of the eCos installer, eCos host tools, GNU compilation tools and eCos build system: gcc libmpfr1 libpng12 make patch tcltk sharutils wget ------------------------------------------------------------------------------ eCos 3.0 Errata --------------- * Compilation of eCos has been tested for those targets which use the following GNU toolchains: arm-eabi arm-elf i386-elf mipsisa32-elf m68k-elf powerpc-eabi sh-elf Compilation of eCos for targets using other toolchains is untested and may not work correctly. * The pre-built arm-eabi toolchain does not support ARM7DI and StrongARM processors. When building eCos for such targets, developers are advised to use the older arm-elf toolchain based on GCC 3.2.1. * Occasional internal compiler errors have been observed when building eCos and tests with the prebuilt m68k-elf toolchain. Such errors are highly sensitive to any changes in the source code. In many cases, the compiler optimisation level may be reduced as a workaround. However, note that building the kernel file clock.cxx without optimisation when configured with CYGDBG_USE_ASSERTS will also trigger an internal compiler error. In such cases, removal of the the compiler flag '-fomit-frame-pointer' may serve as a workaround. * The cxxsupp test fails for target 'linux' (the synthetic target) on certain recent Linux distributions (eg Fedora 10). This failure arises when libgcc assumes that glibc has initialised the GS register to reference per-thread data. * Compilation of the eCos C library for target 'linux' (the synthetic target) is known to fail when using certain older versions of GCC (eg GCC 3.2) due to a duplicate definition of getc(). * Compilation of eCos for targets 'atlas_mips64_5kc' and 'malta_mips64_5kc' fails due to various errors involving a loss of precision while casting. * Compilation of eCos for targets 'cma28x' and 'fads' fails due to a dependency of CYGPKG_HAL_POWERPC_MPC8xx on CYGPKG_HAL_QUICC. * Compilation of eCos for target 'iq80310' fails due to multiple coding issues within the platform support files. * The eCos tests 'pselect' and 'cpuload' may fail erroneously on some eCos targets (false negative). * eCos lwIP tests may fail to build when CYGDBG_LWIP_DEBUG is enabled due to a dependency on snprintf(). * The eCos tests 'except1' and 'kexcept1' may fail on certain processors where an exception is not raised in response to bad alignment (for example). * The eCos math library test 'pow' is known to fail on SH4 hardware when using the prebuilt sh-elf toolchain. The cause is unknown but the problem does not occur with older toolchains. * The MPC8xx test 'intr0' fails on many MPC8xx targets since the test is not generalised for correct operation will all MPC8xx CPUs. * The PSIM PowerPC simulator treats all data cache instructions as noops. The behaviour is benign with the exception of the dcbz instruction. It causes the eCos 'kcache2' test to fail on target 'psim'. * There are a number of minor issues with the eCos Configuration Tool: 84946 Configtool build progress bar inoperative 89778 Configtool platforms list is not sorted 1000619 Configuration tree does not respond to scroll wheel 1000716 Error launching GDB to run eCos tests ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: eCos 3.0 beta 1 remaining issues 2009-03-25 11:01 ` John Dallaway @ 2009-03-25 12:22 ` Bart Veer 2009-03-25 13:05 ` John Dallaway 0 siblings, 1 reply; 5+ messages in thread From: Bart Veer @ 2009-03-25 12:22 UTC (permalink / raw) To: John Dallaway; +Cc: ecos-maintainers >>>>> "John" == John Dallaway <john@dallaway.org.uk> writes: John> eCos maintainers John> I think the eCos 3.0 branch is now good for a final release. John> Thank you to all those who have helped in resolving the last John> few Bugzilla issues. I have appended notes on the action John> taken. I have also attached a draft version of the release John> notes. John> If you have any comments or concerns, please raise them by John> the end of Thursday 2009-03-25. I will then proceed with John> generating the final release. During QA testing of an upcoming eCosPro release, Ross has found a problem in the C library's signal package. It is fairly simple to reproduce. ecosconfig new pc default (any target using a recent compiler will do) ecosconfig add fileio enable CYGPKG_IO_SERIAL_TERMIOS_TERMIOS0 make tests The build will fail with duplicate definitions of cyg_libc_signals_lock() and _unlock(). The problem is caused by this patch: 2008-12-24 Andrew Lunn <andrew.lunn@ascom.ch> * include/signal.inl: (cyg_libc_signals_[un]lock): remove the static from these inline functions which are used by the none static inline signal() and raise(). The patch successfully eliminated some warnings but also changed the inlining semantics of those functions. The compiler is now generating real code for these functions, as well as inlining them, so if more than one module tries to use signal() or raise() then you'll get multiple definitions. There is a simple quick fix: Index: signal.inl =================================================================== RCS file: /cvs/ecos/ecos/packages/language/c/libc/signals/current/include/signal.inl,v retrieving revision 1.7 diff -u -p -r1.7 signal.inl --- signal.inl 29 Jan 2009 17:49:52 -0000 1.7 +++ signal.inl 25 Mar 2009 12:02:02 -0000 @@ -102,7 +102,7 @@ extern void cyg_libc_signals_lock_do_unl // cyg_libc_signals_lock() // ///////////////////////////// -inline cyg_bool +extern __inline__ cyg_bool cyg_libc_signals_lock(void) { #ifdef CYGSEM_LIBC_SIGNALS_THREAD_SAFE @@ -116,7 +116,7 @@ cyg_libc_signals_lock(void) // cyg_libc_signals_unlock() // /////////////////////////////// -inline void +extern __inline__ void cyg_libc_signals_unlock(void) { #ifdef CYGSEM_LIBC_SIGNALS_THREAD_SAFE This again prevents the compiler from generating real code for the functions, so the duplicate definitions go away. I think this is a sensible fix, but obviously it has not been tested. At this stage of the release process I'll wait for approval before checking it in. This also indicates a wider problem with the extensive use of C inline functions in parts of the system. We appear to be dependent on GNU C89 inlining (see the gcc info pages, C extensions, Inline). That could cause problems if people start messing with -std=c99 or similar compiler flags. It also leaves us open to possible changes in gcc behaviour - I don't know what the compiler folks are planning in this area. However, we can worry about the wider implications later. I have not searched for other, similar changes. Andrew, were there any other packages where you eliminated compiler warnings by removing "static" from inline functions. John, Jifl: any objections to me checking in this fix? Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ** Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv> ** ** Mar 31-2 Apr 2009, Booth 221, San Jose McEnery Convention Center ** ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: eCos 3.0 beta 1 remaining issues 2009-03-25 12:22 ` Bart Veer @ 2009-03-25 13:05 ` John Dallaway 2009-03-25 14:37 ` Bart Veer 0 siblings, 1 reply; 5+ messages in thread From: John Dallaway @ 2009-03-25 13:05 UTC (permalink / raw) To: Bart Veer; +Cc: ecos-maintainers Hi Bart Bart Veer wrote: >>>>>> "John" == John Dallaway <john@dallaway.org.uk> writes: > > John> If you have any comments or concerns, please raise them by > John> the end of Thursday 2009-03-25. I will then proceed with > John> generating the final release. BTW, that should read Thursday 2009-03-26. > During QA testing of an upcoming eCosPro release, Ross has found a > problem in the C library's signal package. It is fairly simple to > reproduce. > > ecosconfig new pc default (any target using a recent compiler will do) > ecosconfig add fileio > enable CYGPKG_IO_SERIAL_TERMIOS_TERMIOS0 > make tests > > The build will fail with duplicate definitions of > cyg_libc_signals_lock() and _unlock(). The problem is caused by this > patch: > > 2008-12-24 Andrew Lunn <andrew.lunn@ascom.ch> > > * include/signal.inl: (cyg_libc_signals_[un]lock): remove the > static from these inline functions which are used by the none > static inline signal() and raise(). > > The patch successfully eliminated some warnings but also changed the > inlining semantics of those functions. The compiler is now generating > real code for these functions, as well as inlining them, so if more > than one module tries to use signal() or raise() then you'll get > multiple definitions. > > There is a simple quick fix: > > Index: signal.inl > =================================================================== > RCS file: /cvs/ecos/ecos/packages/language/c/libc/signals/current/include/signal.inl,v > retrieving revision 1.7 > diff -u -p -r1.7 signal.inl > --- signal.inl 29 Jan 2009 17:49:52 -0000 1.7 > +++ signal.inl 25 Mar 2009 12:02:02 -0000 > @@ -102,7 +102,7 @@ extern void cyg_libc_signals_lock_do_unl > // cyg_libc_signals_lock() // > ///////////////////////////// > > -inline cyg_bool > +extern __inline__ cyg_bool > cyg_libc_signals_lock(void) > { > #ifdef CYGSEM_LIBC_SIGNALS_THREAD_SAFE > @@ -116,7 +116,7 @@ cyg_libc_signals_lock(void) > // cyg_libc_signals_unlock() // > /////////////////////////////// > > -inline void > +extern __inline__ void > cyg_libc_signals_unlock(void) > { > #ifdef CYGSEM_LIBC_SIGNALS_THREAD_SAFE > > > This again prevents the compiler from generating real code for the > functions, so the duplicate definitions go away. I think this is a > sensible fix, but obviously it has not been tested. At this stage of > the release process I'll wait for approval before checking it in. [ snip ] > John, Jifl: any objections to me checking in this fix? Looking at the CVS logs, Andrew's change of 2008-12-24 was part of series of check-ins targeting compiler warnings in general. None of the other changes involved modifying inlined functions so I expect this is an isolated regression. From my perspective, it is clearly desirable to fix this for 3.0 but it is indeed late in the release cycle so I would ask that you do perform a basic run-time sanity test against the ecos-v3_0-branch before committing it. Best to use one of the new pre-built eCos toolchains (GCC 4.3.2) for this. Thanks John Dallaway ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: eCos 3.0 beta 1 remaining issues 2009-03-25 13:05 ` John Dallaway @ 2009-03-25 14:37 ` Bart Veer 0 siblings, 0 replies; 5+ messages in thread From: Bart Veer @ 2009-03-25 14:37 UTC (permalink / raw) To: John Dallaway; +Cc: ecos-maintainers >>>>> "John" == John Dallaway <john@dallaway.org.uk> writes: <snip> >> John, Jifl: any objections to me checking in this fix? John> Looking at the CVS logs, Andrew's change of 2008-12-24 was John> part of series of check-ins targeting compiler warnings in John> general. None of the other changes involved modifying John> inlined functions so I expect this is an isolated John> regression. John> From my perspective, it is clearly desirable to fix this for John> 3.0 but it is indeed late in the release cycle so I would John> ask that you do perform a basic run-time sanity test against John> the ecos-v3_0-branch before committing it. Best to use one John> of the new pre-built eCos toolchains (GCC 4.3.2) for this. Tested on m5272c3 and synthetic target, and checked in to the V3 branch and the trunk. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ** Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv> ** ** Mar 31-2 Apr 2009, Booth 221, San Jose McEnery Convention Center ** ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-03-25 14:37 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-03-20 11:31 eCos 3.0 beta 1 remaining issues John Dallaway 2009-03-25 11:01 ` John Dallaway 2009-03-25 12:22 ` Bart Veer 2009-03-25 13:05 ` John Dallaway 2009-03-25 14:37 ` Bart Veer
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).