Revised release criteria for GCC 4.0

[Peter Barada]

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

I think this is something we vhave to either do ourselves, or convince
people that produce boards and distribute GNU cross-toolchains to
support.  Personally, I was in a bread-line begging for toast to get
the 547x board that I have :)

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

Hmm, I haven't thought of all the issues attached to this :)  I didn't
know that the regression test has tests that actually try to
*crash*.  Perhaps it could be culled down to a list that runs without
requiring a full-blown protective model?  As for the mechanics, I
defer to someone who's actually doing remote testing(alas, that list
doens't include me).

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

I build uberbaum for m68k-elf as I'm trying to work on issues relating
to ColdFire.  I haven't yet tried to run the regression test.  I've
looked over Dan's great notes but haven't had any spare time to
try out his method.

I'm sure that there are enough of us that regularly use(and abuse)
some of the cross targets that perhaps we should get together to share
information on how to build/test/verify what we work with.

Who's interested(I am!)?  I have a few ColdFire targets I can beat up
given help from someone who's actually gone through this saga before :)

>Testing with newlib is not an option for most targets!

I figured at absolute *minima*, building newlib for the cross-targets
would be a decent exercise of the cross-compiler....

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

I agree with you in principal, but unfortunately the full
cross-toolchain includes components outside of GCC, so coordinating
changes between each of the components will be difficult.  I'd still
like to see a release criteria that identified versions of the cross
components(of binutils, newlib and glibc) that would be used to build
cross-targets just to be sure that they still build.

My biggest fear is that as the list of primary  and secondary targets
shrinks and only includes two raw elf targets(mips/arm), that those of
us that create/use cross-compilers orr the other targets may get left
unintentionally in the dark, and have to patch our way to a working
cross-toolchain.

-- 
Peter Barada
peter@the-baradas.com