This is the mail archive of the ecos-maintainers@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: eCos 3.0 beta 1 remaining issues


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]