This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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: Revised release criteria for GCC 4.0


Peter Barada wrote:
From my past experience with the m68k-elf target, I've learned that many

tests assume a full-blown libc and an underlying OS.


Now that the 5475/5485 ColdFire parts/eval boards exist, there's a
full Linux that supports it, and can be used to test it :)

Fine! So far, I only had an old Amiga (68060 @ 50MHz) to run the testsuite on. It took ages and the CPU would also occasionally overheat, failing tests randomly ;-)

Would it be possible to donate one board to GCC or CodeSourcery
for the automatic regression tester?  This would ensure in the
future nobody will ever break the m68k target by mistake (at least
for ColdFire).


In the case of the other less-powerful parts, can uClinux be used to
do testing?  If so, then there are *many* more platforms that can be
rigorously tested(assuming people volunteer their time to run the
tests on the platforms that they have access to).

There were lots of stability issues with uClinux on a 5272C3 board, mostly caused by lack of RAM (1MB free after boot), memory fragmentation and corruption (some tests *intentionally* trash memory and expect it to cause a segfault!).

Besides, uploding the tests via rcp on a JFFS2 filesystem took even
longer than executing them.

I should have used a trick with NFS (for which there was no ready
support in Dejagnu) or upload the tests in a tmpfs (which would have
fragmented memory even more).


As the toolchain evolves, its becoming much harder to build a
cross-toolchain, and would be next to impossible without the work of
Dan Kegel and others to make crosstool capable of building
cross-toolchains.

I do agree. Building a cross-toolchain in uberbaum would be ideal. The biggest obstacle is that few people test it and many libc variants are not readily pluggable into the src repository, most notably glibc and uClibc.

Testing with newlib is not an option for most targets!


I hope that future development does not preclude
the creation of working cross-compilers, and I'd like to see the
addition to the release criteria that GCC has to configure/build
cross-compilers for a set of targets, and perhaps build up a full
cross-toolchain as a way to stress it.

I agree here. In the long term, building cross-toolchains should be automated using the top-level machinery.

Building them all with a single script would be great.

Sometimes we could even run the testsuite with a GDB
simulator.

--
 // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/


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