Revised release criteria for GCC 4.0

Bernardo Innocenti bernie@develer.com
Mon Dec 13 18:26:00 GMT 2004


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/



More information about the Gcc mailing list