eCos 3.0 beta 1 punch list #1

eCos 3.0 beta 1 punch list #1

[John Dallaway]

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

Re: eCos 3.0 beta 1 punch list #1

[Bart Veer]

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

Re: eCos 3.0 beta 1 punch list #1

[Jonathan Larmour]

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

Re: eCos 3.0 beta 1 punch list #1

[Andrew Lunn]

> 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

Target-specific build failures [ was Re: eCos 3.0 beta 1 punch list #1 ]

[John Dallaway]

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

Re: eCos 3.0 beta 1 punch list #1

[Bart Veer]

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