* 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
* 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
* 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
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).