public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
* 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).