* eCos 3.0 beta 1 punch list #1 @ 2009-02-01 17:51 John Dallaway 2009-02-03 22:10 ` Bart Veer 0 siblings, 1 reply; 6+ messages in thread From: John Dallaway @ 2009-02-01 17:51 UTC (permalink / raw) To: ecos-maintainers eCos Maintainers Following discussion with Jifl today, the initial release will be referred to as "eCos 3.0 beta 1" and will be announced to ecos-discuss only for testing by the eCos community. Assuming there are no significant issues, this will be followed by the final release 1-2 weeks later. Please note that the CVS repository is still frozen but should re-open soon for final commits before the release branch is cut. If you are aware of patches which you would like to commit before we branch but could have a destabilizing effect, please discuss on this list first. Here is the current punch list for eCos 3.0 beta 1: a) Constructor priority re-ordering work. (bartv) b) CDL changes to split compiler warning flags out into a separate CDL option. (bartv) c) Addition of eh_frame section to SH3 .ldi files to allow for linking of the cxxsupp test. (john) d) Fix/workaround for linking of cxxsupp test for ARM targets using the old arm-elf toolchain based on gcc-3.2.1. (jifl) e) Reverting of eCos build for ebsa285 (StrongARM) target to use arm-elf toolchain in line with other StrongARM targets. (john) f) Verification of eCos build under Cygwin binary mode filesystem. (john) g) Final ConfigTool tweaks. (john) h) README.host review/update. (john/jifl) i) Review of i386 and MIPS32 linking issues reported previously to ensure everything is now resolved. (jifl) j) Investigation and workaround for m68k compiler issue at -O0 -fomit-frame-pointer with CYGDBG_USE_ASSERTS. (jifl) k) Removal of obsolete package CYGPKG_DEVS_FLASH_SST_39VF400 from repository. (john) l) Removal of ecos.db package records for the deprecated CYGPKG_*_COLDFIRE* packages to avoid end-user confusion. (john) m) Test of support for multiple releases in ecos-install.tcl. (john) n) Cygwin-hosted sh-elf toolchain spin to match linux-hosted version dated 2009-01-21. (jifl) o) Addition of CYGPKG_IO_SPI to relevant target records in ecos.db. (john) Everyone, please advise me immediately of any other critical issues for eCos 3.0 known to you. Changes between the beta 1 and final releases will be limited to issues revealed during beta 1 evaluation. While the beta 1 release is being exercised by the community, we can work on website updates for eCos 3.0. Many site changes are desirable, but not necessarily critical, for the final release. Jifl will generate a list of what _he_ is intending to tackle in this period in advance. This will include: * Copyright assignment information update (blocker for 3.0 final) * Completion of eCos FAQ transfer from FAQ-O-Matic to Wiki * Update of hardware table Please feel free to offer updates to other aspects of the site and liaise via this list to avoid conflicts and/or duplicated effort. John Dallaway eCos 3.0 release manager ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: eCos 3.0 beta 1 punch list #1 2009-02-01 17:51 eCos 3.0 beta 1 punch list #1 John Dallaway @ 2009-02-03 22:10 ` Bart Veer 2009-02-04 0:56 ` Jonathan Larmour ` (2 more replies) 0 siblings, 3 replies; 6+ messages in thread From: Bart Veer @ 2009-02-03 22:10 UTC (permalink / raw) To: John Dallaway; +Cc: ecos-maintainers >>>>> "John" == John Dallaway <john@dallaway.org.uk> writes: John> b) CDL changes to split compiler warning flags out into a John> separate CDL option. (bartv) This is now complete. I have now finished in the hal/ directory, so I have no objection to people checking in more changes in there. There are an awful lot of platforms which fail to build. ARM AEB, all SA1110: cxxsupp fails to link because of .gcc_except_table. XSEngine, mcp50: /work/projects/update_cflags/arm/build/install/include/cyg/hal/hal_cache.h:63:10: error: #include expects "FILENAME" or <FILENAME> iq80310: /work/projects/update_cflags/arm/build/install/include/cyg/hal/hal_platform_setup.h:124: Error: Macro `delay_for' was already defined /work/projects/update_cflags/arm/build/install/include/cyg/hal/hal_platform_setup.h:131: Error: Macro `cpwait' was already defined npwr: /work/projects/update_cflags/arm/build/install/include/cyg/hal/hal_platform_setup.h:126: Error: Macro `delay_for' was already defined /work/projects/update_cflags/arm/build/install/include/cyg/hal/hal_platform_setup.h:133: Error: Macro `cpwait' was already defined /work/projects/update_cflags/arm/build/install/include/cyg/hal/hal_platform_setup.h:140: Error: Macro `fl_section_entry' was already defined /work/projects/update_cflags/arm/build/install/include/cyg/hal/hal_platform_setup.h:146: Error: Macro `fl_pt_entry' was already defined /work/projects/update_cflags/arm/build/install/include/cyg/hal/hal_platform_setup.h:154: Error: Macro `sl_smpage_entry' was already defined /work/projects/update_cflags/arm/build/install/include/cyg/hal/hal_platform_setup.h:160: Error: Macro `sl_xsmpage_entry' was already defined MIPS atlas_mips64_5kc: malta_mips64_5kc: Warnings for everything virtual-vector related. Errors because casts from pointer to CYG_WORD lose precision. jmr3904: tx39_sim: Still uses mips-tx39-elf-gcc, which I don't have lying around. refidt334: ocelot: cxxsupp fails to build, .gcc_except_table ref4955: Still uses mips-tx49-elf-gcc, which I don't have lying around. vrc4373: vrc4375: Still uses mips64vr4300-elf-gcc, which... PowerPC cma28x: fads: /work/ecos/trunk/packages/hal/powerpc/mpc8xx/current/src/var_misc.c:57:34: error: cyg/hal/quicc/ppc8xx.h: No such file or directory mbx: /work/ecos/trunk/packages/hal/powerpc/mbx/current/tests/mbxtime.cxx:103: undefined reference to `thread2' /work/ecos/trunk/packages/hal/powerpc/mbx/current/tests/mbxtime.cxx:103: undefined reference to `thread2' viper: /work/ecos/trunk/packages/hal/powerpc/viper/current/tests/vipertime.cxx:103: undefined reference to `thread2' /work/ecos/trunk/packages/hal/powerpc/viper/current/tests/vipertime.cxx:103: undefined reference to `thread2' ts1000: /work/ecos/trunk/packages/hal/powerpc/ts1000/current/cdl/hal_powerpc_ts1000.cdl, component CYGPKG_REDBOOT_HAL_OPTIONS: error Option `CYGSEM_REDBOOT_HAL_LINUX_BOOT' cannot be loaded. The name is already in use. SH All platforms fail to build cxxsupp i386, cortexm, and m68k all build fine. I have not tried anything with the calmrisc16, calmrisc32, coldfire, fr30, frv, h8300, mn10300, openrisc, sparc, sparclite or v85x targets. The synthetic target builds fine, but there is a run-time problem with cxxsupp. It appears that libgcc now assumes that glibc has done some initialization, setting up the %gs register to point at per-thread data. This came up previously in the context of the -fstack-protector flag, see the mailing list archives, but at the time we decided we could live with the problem. It looks like there are now more dependencies on getting this sorted - which I suspect will prove challenging. 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: eCos 3.0 beta 1 punch list #1 2009-02-03 22:10 ` Bart Veer @ 2009-02-04 0:56 ` Jonathan Larmour 2009-02-04 6:47 ` Andrew Lunn 2009-02-04 9:22 ` Target-specific build failures [ was Re: eCos 3.0 beta 1 punch list #1 ] John Dallaway 2 siblings, 0 replies; 6+ messages in thread From: Jonathan Larmour @ 2009-02-04 0:56 UTC (permalink / raw) To: Bart Veer; +Cc: John Dallaway, ecos-maintainers Bart Veer wrote: >>>>>>"John" == John Dallaway <john@dallaway.org.uk> writes: > > > John> b) CDL changes to split compiler warning flags out into a > John> separate CDL option. (bartv) > > This is now complete. I have now finished in the hal/ directory, so I > have no objection to people checking in more changes in there. The other thing that had been said before while there was a code freeze was the init priority and io/flash changes. Ping me on IRC tomorrow (Wednesday) and we can talk about whether it's ok to unfreeze things. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["The best things in life aren't things."]------ Opinions==mine ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: eCos 3.0 beta 1 punch list #1 2009-02-03 22:10 ` Bart Veer 2009-02-04 0:56 ` Jonathan Larmour @ 2009-02-04 6:47 ` Andrew Lunn 2009-02-04 10:08 ` Bart Veer 2009-02-04 9:22 ` Target-specific build failures [ was Re: eCos 3.0 beta 1 punch list #1 ] John Dallaway 2 siblings, 1 reply; 6+ messages in thread From: Andrew Lunn @ 2009-02-04 6:47 UTC (permalink / raw) To: Bart Veer; +Cc: John Dallaway, ecos-maintainers > The synthetic target builds fine, but there is a run-time problem with > cxxsupp. It appears that libgcc now assumes that glibc has done some > initialization, setting up the %gs register to point at per-thread > data. This came up previously in the context of the -fstack-protector > flag, see the mailing list archives, but at the time we decided we > could live with the problem. It looks like there are now more > dependencies on getting this sorted - which I suspect will prove > challenging. What gcc and glibc are you using? For me cxxsupp runs and passes. So as always, it seems to very from system to system: lunn@londo:~/eCos/work$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-3' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.3 (Debian 4.3.3-3) $ /lib/libc.so.6 GNU C Library stable release version 2.7, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.3.2. Compiled on a Linux >>2.6.26.1<< system on 2009-01-04. Andrew ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: eCos 3.0 beta 1 punch list #1 2009-02-04 6:47 ` Andrew Lunn @ 2009-02-04 10:08 ` Bart Veer 0 siblings, 0 replies; 6+ messages in thread From: Bart Veer @ 2009-02-04 10:08 UTC (permalink / raw) To: Andrew Lunn; +Cc: john, ecos-maintainers >>>>> "Andrew" == Andrew Lunn <andrew.lunn@ascom.ch> writes: >> The synthetic target builds fine, but there is a run-time problem with >> cxxsupp. It appears that libgcc now assumes that glibc has done some >> initialization, setting up the %gs register to point at per-thread >> data. This came up previously in the context of the -fstack-protector >> flag, see the mailing list archives, but at the time we decided we >> could live with the problem. It looks like there are now more >> dependencies on getting this sorted - which I suspect will prove >> challenging. Andrew> What gcc and glibc are you using? For me cxxsupp runs and Andrew> passes. So as always, it seems to very from system to Andrew> system: Andrew> lunn@londo:~/eCos/work$ gcc -v Andrew> Using built-in specs. Andrew> Target: i486-linux-gnu Andrew> Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-3' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Andrew> Thread model: posix Andrew> gcc version 4.3.3 (Debian 4.3.3-3) Andrew> $ /lib/libc.so.6 Andrew> GNU C Library stable release version 2.7, by Roland McGrath et al. Andrew> Copyright (C) 2007 Free Software Foundation, Inc. Andrew> This is free software; see the source for copying conditions. Andrew> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A Andrew> PARTICULAR PURPOSE. Andrew> Compiled by GNU CC version 4.3.2. Andrew> Compiled on a Linux >>2.6.26.1<< system on 2009-01-04. An up-to-date Fedora 10 system. gcc 4.3.2-7, libc 2.9. However I am not sure that really matters. The writing is on the wall: the synthetic target will need %gs support in the not too distant future to remain fully functional on a range of Linux distributions. I don't know when I'll have time to look into this. 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Target-specific build failures [ was Re: eCos 3.0 beta 1 punch list #1 ] 2009-02-03 22:10 ` Bart Veer 2009-02-04 0:56 ` Jonathan Larmour 2009-02-04 6:47 ` Andrew Lunn @ 2009-02-04 9:22 ` John Dallaway 2 siblings, 0 replies; 6+ messages in thread From: John Dallaway @ 2009-02-04 9:22 UTC (permalink / raw) To: Bart Veer; +Cc: ecos-maintainers Hi Bart and all Bart Veer wrote: >>>>>> "John" == John Dallaway <john@dallaway.org.uk> writes: > > John> b) CDL changes to split compiler warning flags out into a > John> separate CDL option. (bartv) > > This is now complete. I have now finished in the hal/ directory, so I > have no objection to people checking in more changes in there. That's great news. Thank you. > There are an awful lot of platforms which fail to build. > > ARM > AEB, all SA1110: cxxsupp fails to link because of .gcc_except_table. This on the punch list for jifl to investigate. [ snip various build failures ] Most of the failures you list are for old/obsolete targets that may no longer be in use within the eCos community. While we could systematically go through all these failures, I don't see this as a good use of our time right now. We know that architectural support for the main architectures is in good shape. Everyone, if there are targets in the list that you care about, please volunteer to fix as soon as possible. > SH > All platforms fail to build cxxsupp I have a patch for this issue. > I have not tried anything with the calmrisc16, calmrisc32, coldfire, > fr30, frv, h8300, mn10300, openrisc, sparc, sparclite or v85x targets. The old "coldfire" HAL and associated target will not form part of the release. The other architectures will simply not be tested (even for build regressions) unless someone shows an interest in these targets. > The synthetic target builds fine, but there is a run-time problem with > cxxsupp. It appears that libgcc now assumes that glibc has done some > initialization, setting up the %gs register to point at per-thread > data. This came up previously in the context of the -fstack-protector > flag, see the mailing list archives, but at the time we decided we > could live with the problem. It looks like there are now more > dependencies on getting this sorted - which I suspect will prove > challenging. We always seem to be playing catch up with gcc/glibc for the synthetic target. If you have time to investigate the cxxsupp build failure then, of course, feel free. However, I don't see this as a showstopper, at least not for the beta release. We can always document the compatibility issue in the README. For avoidance of doubt, please do finish off the constructor priority re-work first so we can unfreeze the repository for final check-ins and I can commence further sanity tests across the entire repository. When do you envisage being able to check this in? Jifl/Bart, could we limit the scope of the code freeze to those packages that form part of the constructor priority re-work now? John Dallaway ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-02-04 10:08 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-02-01 17:51 eCos 3.0 beta 1 punch list #1 John Dallaway 2009-02-03 22:10 ` Bart Veer 2009-02-04 0:56 ` Jonathan Larmour 2009-02-04 6:47 ` Andrew Lunn 2009-02-04 10:08 ` Bart Veer 2009-02-04 9:22 ` Target-specific build failures [ was Re: eCos 3.0 beta 1 punch list #1 ] John Dallaway
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).