--nHJAUhyIZkPvF01C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Folks...

I'm working on a toolchain upgrade plan for post-1.6 NetBSD.  I'm to
the point where I would appreciate comments on the plan, and would also
like to field any questions you might have about it.

It is attached.  Please make sure to keep tech-toolchain on the CC list,
as I want to make sure all discussion about this topic is archived.

Thanks.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

--nHJAUhyIZkPvF01C
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="toolchain-plan.txt"

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

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 (mostly target support)

	Binutils 2.11.2 + local patches (mostly target support)

	GDB 5.1 + 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)
		i386-netbsdelf
		m68010-netbsdelf
		m68k-netbsdelf
		mips*-netbsdelf
		powerpc-netbsd (has some problems)
		sparc-netbsdelf
		sparc64-netbsdelf (requires -D_LP64 patch)
		x86_64-netbsdelf (requires -D_LP64 patch)

		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*-netbsdelf
			powerpc-netbsd (has some problems)
			sparc-netbsdelf
			sparc64-netbsdelf
			x86_64-netbsdelf

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

			sh*-netbsdelf
				(have patches, pending approval getting
				them into the tree.  SH compiler still
				has fairly major issues in gcc-current)

			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)

	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
			armeb-netbsdelf
			i386-netbsdelf
			mips*-netbsd
			powerpc-netbsd (needs fixing, in-progress)
			sh*-netbsdelf
			sparc-netbsdelf
			sparc64-netbsd
				(basic support commit pending, but needs
				lots of bugs fixed in shared SPARC taget
				code, should try to work with Linux/sparc64
				folks on this)

		Missing:
			m68k-netbsdelf (target must first be "multi-arch'd")
			vax-netbsdelf (waiting on matt@netbsd.org for bfd)
			x86_64-netbsd

II. Target Toolchain Component Versions

	A. GCC 3.2

	Rationale:

		GCC 3.2 will, if all goes well, support all NetBSD ELF
		targets out-of-box.  GCC 3.2 will also contain the
		necessary preprocessor support for our lint(1), and also
		has the necessary changes to the printf-format checking
		code to support e.g.  BSD warn(3), err(3), etc. (for which
		NULL is a valid format argument).

		GCC 3.2 will also have noticeable performance improvements
		of the compiler itself over GCC 3.1 (there have been many
		complaints recently about how GCC 3.1 is unacceptably slow
		compared to 2.95.3).

		GCC 3.2 is scheduled for release in December 2002.  It
		may be acceptable to import development versions of the
		compiler into the tree to track until the 3.2 release
		is made, so long as we do not ship an actual NetBSD release
		with a non-release compiler.

	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.

		I do not yet have a tentative release date for GDB 5.3.

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


--nHJAUhyIZkPvF01C--