Subject: UPDATED DRAFT -- Toolchain upgrade plan
To: None <tech-toolchain@netbsd.org>
From: Jason R Thorpe <thorpej@wasabisystems.com>
List: tech-toolchain
Date: 05/31/2002 16:44:23
This updates status of several tool components, and also reflects
pushback I got on GCC 3.2 (I've switched to GCC 3.1.1 as a target
compiler version).


NetBSD Toolchain Upgrade Plan -- DRAFT
====================================
Jason R. Thorpe <thorpej@netbsd.org>
Last updated: 2002-05-31

First of all, it is imporant to note that the 3 major toolchain components
(GCC, Binutils, and GDB) all support ns32k-netbsd out of the box, but only
for statically linked executables.  The GCC maintainers are threatening to
delete the ns32k target unless a maintainer steps forward.  I have recently
rescued ns32k support in GDB from being deleted (by making an overhaul
required for continued inclusion in the GDB source tree).  IF WE WANT TO
CONTINUE TO SUPPORT NS32K, SOMEONE NEEDS TO STEP UP TO THE PLATE AND DO
THE NECESSARY WORK ON THE TOOLCHAIN.  I simply cannot stress this enough.
If you are serious about taking on this task, then perhaps the PC532 in
Herb's build lab can be sent your way (this is speculation, but I don't
think Herb would object).

That said, I am going to now focus ONLY on ELF platforms which currently
use the "new toolchain" cross-build framework in the NetBSD source tree.

There are also two platforms that I am mostly ignoring in this document:
ia64-netbsd and hppa-netbsd.  The IA64 port is only in the beginning
stages, and the HPPA port has not been committed the source tree, yet,
so I don't have any way to test any of its toolchain components.

Also, I am the "NetBSD host and target maintainer" for both GCC and
GDB, and I have commit privs to the master CVS repositories for GCC,
Binutils, and GDB.  If you need need to make changes to the toolchain,
you should discuss them with me, first.  And if you are going to make
a non-trivial change, then I will insist that you take care of getting
FSF copyright assignments filed, otherwise I cannot commit your change
back upstream, which puts us back in the same unpleasant situation we've
been in for years.

I. Current Status

The NetBSD OS currently uses the following versions of the GNU toolchain
components:

	GCC 2.95.3 + local patches (some target support, plus several
	bug fixes)

	Binutils 2.11.2 + local patches (mostly target support)

	GDB 5.0 + local patches (mostly target support)

The current release verions of these tools, and the NetBSD targets they
support, are:

	A. GCC 3.1

		alpha-netbsd (requires -D_LP64 patch; fixed for 3.1.1)
		i386-netbsdelf
		m68010-netbsdelf
		m68k-netbsdelf
		mips*-netbsd
		powerpc-netbsd (has some problems)
		sparc-netbsdelf
		sparc64-netbsd (requires -D_LP64 patch; fixed for 3.1.1)
		x86_64-netbsd (requires -D_LP64 patch; fixed for 3.1.1)

		Missing:
			arm-netbsdelf
			armeb-netbsdelf
			sh*-netbsdelf
			vax-netbsdelf

		GCC also has some known problems with the NetBSD
		source tree:

			-CC not supported in preprocessor (fixed in
			GCC 3.2)

			-Wformat warns about zero-length format strings
			(fixed in GCC 3.2; -Wno-format-zero-lengh added)

			-Wformat warns about NULL format arguments
			(fixed in GCC 3.2; __attribute__((nonnull)))

		GCC-current supports:
			alpha-netbsd
			i386-netbsdelf
			m68010-netbsdelf
			m68k-netbsdelf
			mips*-netbsd
			powerpc-netbsd (has some problems)
			sh*-netbsdelf
			sparc-netbsdelf
			sparc64-netbsd
			x86_64-netbsd

		Missing:
			arm-netbsdelf
			armeb-netbsdelf
				(have patches, but they don't work; need
				help from Richard Earnshaw on ARM target)

			vax-netbsdelf (waiting on matt@netbsd.org)

	B. Binutils 2.12.1

		alpha-netbsd
		arm-netbsdelf (may be problems, need to investigate)
		hppa-netbsd
		i386-netbsdelf
		ia64-netbsd
		powerpc-netbsd
		m68010-netbsdelf
		m68k-netbsdelf
		mips*-netbsd
		sh*-netbsdelf
		sparc-netbsdelf
		sparc64-netbsd
		x86_64-netbsd

		Missing:
			armeb-netbsd (easy to add, in bintuils-current)
			vax-netbsdelf (waiting on matt@netbsd.org)

		Binutils-current supports:

			alpha-netbsd
			arm-netbsdelf (may be problems, need to investigate)
			armeb-netbsdelf
			hppa-netbsd 
			i386-netbsdelf  
			ia64-netbsd
			powerpc-netbsd
			m68010-netbsdelf
			m68k-netbsdelf
			mips*-netbsd
			sh*-netbsdelf
			sparc-netbsdelf
			sparc64-netbsd
			x86_64-netbsd
			vax-netbsdelf (missing gas; waiting on matt@netbsd.org)

	C. GDB 5.2

		GDB 5.2 does not support nearly enough NetBSD platforms,
		and so it is simply not listed here.  This is being
		addressed for GDB 5.3.  GDB-current supports the
		following targets:

			alpha-netbsd
			arm-netbsdelf [1]
			armeb-netbsdelf
			i386-netbsdelf
			mips*-netbsd
			powerpc-netbsd [2]
			sh*-netbsdelf
			sparc-netbsdelf [3]
			sparc64-netbsd [4]

		[1] Cross-debugging of user binaries needs fixing.

		[2] Signal support, longjmp support, and some other
		    random things need fixing.

		[3] Signal support needs fixing.

		[4] Signal support needs fixing, lots of random sparc64
		    bugs in generic SPARC target code.

		Missing:
			m68k-netbsdelf (target must first be "multi-arch'd")
			vax-netbsdelf
			x86_64-netbsd

II. Target Toolchain Component Versions

	A. GCC 3.1.1

	Rationale:

		GCC 3.1.1 will support most of the NetBSD platforms.
		Those which are not supported can have support back-ported
		from the GCC mainline.

		Other various support patches can be back-ported from the
		GCC mainline.

		GCC 3.1.1 includes several performance improvements to
		the compiler itself, already brought over from the GCC
		mainline.

		GCC 3.1.1's release schedule is a better match for NetBSD's
		release schedule than GCC 3.2's release schedule.

		GCC 3.1.1 is scheduled for release in July 2002.  3.1.2
		is scheduled for release in September 2002.  It may be
		perfectly acceptable to ship a non-release version of
		the GCC 3.1 branch, as it is a release branch.

		GCC 3.2 is scheduled for release in December 2002.

	B. Binutils 2.12.1 (or latest release on 2.12 branch)

	Rationale:

		With one minor exception (armeb, which was added to
		binutils-current recently), Binutils 2.12 supports all
		NetBSD ELF targets out-of-box.  It is very likely that
		future releases on the 2.12 branch will address the
		missing armeb target, as well.

	C. GDB 5.3

	Rationale:

		GDB 5.3 will, if all goes well, support all NetBSD ELF
		targets out-of-box.  GDB will also support cross-debugging
		of core files (with shared library support) for all supported
		NetBSD targets.

		GDB 5.3 will likely be released around the August/September
		2002 timeframe.

III. Toolchain Component Testing

The "USE_NEW_TOOLCHAIN" framework which is now used as the basis for
building the NetBSD source tree provides mechanisms for using external
toolchain components.  This is already used to e.g. build the x86_64
port.

The same "autobuild" mechanism currently used to do automated builds
of the NetBSD source tree for release engineering purposes will be used
to perform test builds of the NetBSD source tree using external versions
of the target toolchain components (GCC and Binutils).

An automated toolchain component test source tree build will work like this:

	1. CVS update to the selected version of the toolchain component
	   from cvs.netbsd.org.  The target toolchain components are in
	   the toolchain/gcc-3.1 and toolchain/binutils-2.12 modules.

	2. Anoncvs update the NetBSD source mainline.

	3. For each $MACHINE_ARCH for which a test build will be
	   done:

		a. Build a cross-targeted binutils.

		b. Build a cross-targeted gcc.

	4. For each $MACHINE for which a test build will be done:

		a. Copy all libraries and shared libraries built
		   during the GCC build process that are expected
		   to be included in a NetBSD release to
		   ${DESTDIR}/usr/lib.

		b. build.sh -R the target.  (This build will exclude
		   building compiler-related libraries for the target.
		   The mechanism for this already exists in the NetBSD
		   source tree.)

	   The status of each build should be sent to a mailing list
	   (netbsd-testresults).  A successful build will indicate
	   success only.  A failed build will include the tail of
	   the log showing where the failure occurred.

	   The snapshots will be made available for user testing.

IV. Future Toolchain Component Testing

In order to ensure that future toolchain upgrades in NetBSD go smoothly,
and to improve the quality of the toolchain in general, the NetBSD Project
will perform automated testing of the latest GNU toolchain components'
development sources.

An automated toolchain component test source tree build will work like this:

	1. Anoncvs update to the selected version of the toolchain
	   component from the appropriate anoncvs server:

		a. gcc.gnu.org for GCC (tip-of-mainline until 3.2 is
		   branched, then track that branch is made).

		b. sources.redhat.com for Binutils (either select a
		   release and slurp it down once, or track to 2.12
		   release branch).
	
	2. Anoncvs update the NetBSD source mainline.

	3. For each $MACHINE_ARCH for which a test build will be
	   done:

		a. Build a cross-targeted binutils.

		b. Build a cross-targeted gcc.

	4. For each $MACHINE for which a test build will be done:

		a. Copy libgcc.a and libstdc++.a from the GCC
		   lib directory to ${DESTDIR}/usr/lib.

		b. build.sh -d the target.  (This build will exclude
		   building compiler-related libraries for the target.
		   The mechanism for this already exists in the NetBSD
		   source tree.)

	   The status of each build should be sent to a mailing list
	   (netbsd-testresults).  A successful build will indicate
	   success only.  A failed build will include the tail of
	   the log showing where the failure occurred.

Automated automated GCC bootstrap/regression testing for every NetBSD
target will be performed.  In order to do this, a representative host
machine must be selected for each $MACHINE_ARCH that is to be tested.
Because the GCC bootstrap/regression test procedure is intensive, a
reasonably fast system should be selected.

	1. Anoncvs update to the tip-of-the-trunk toolchain component
	   sources from the appropriate anoncvs server:

		a. gcc.gnu.org for GCC (tip-of-mainline until 3.2 is
		   branched, then track that branch is made).

		b. sources.redhat.com for Binutils (either select a
		   release and slurp it down once, or track to 2.12
		   release branch).

	2. Build and install a native binutils.

	3. Perform a GCC bootstrap.  This is a 3-stage build of the
	   compiler:

		a. Builds stage1/xgcc with /usr/bin/cc -O0.

		b. Builds stage2/xgcc with stage1/xgcc -O2.

		c. Builds stage3/xgcc with stage2/xgcc -O2.

		d. Does a byte-for-byte compare of stage2/xgcc
		   and stage3/xgcc, failing if they are not
		   identical.

	4. Perform a "make check" of the compiler resulting from the
	   bootstrap.  This will test all supported components of
	   GCC for the selected platform, including libstdc++-v3.
	   Results of the regression test should be sent to both
	   the netbsd-testresults and gcc-testresults mailing lists.