We were not being consistent.
Standardize on toolchain.
Change-Id: Id0e756b5214ce4a1341f733634ed95263f03a61c
Reviewed-on: https://go-review.googlesource.com/87017
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
example, if we allowed extra configuration such as compiler flags or
command line recipes, then that configuration would need to be updated
each time the build tools changed; it would also be inherently tied
-to the use of a specific tool chain.</p>
+to the use of a specific toolchain.</p>
<h2>Getting started with the go command</h2>
and instruction selection occurs partly after code generation.
The assembler works on the semi-abstract form, so
when you see an instruction like <code>MOV</code>
-what the tool chain actually generates for that operation might
+what the toolchain actually generates for that operation might
not be a move instruction at all, perhaps a clear or load.
Or it might correspond exactly to the machine instruction with that name.
In general, machine-specific operations tend to appear as themselves, while more general concepts like
<p>
There are four predeclared symbols that refer to pseudo-registers.
These are not real registers, but rather virtual registers maintained by
-the tool chain, such as a frame pointer.
+the toolchain, such as a frame pointer.
The set of pseudo-registers is the same for all architectures:
</p>
Note that
<a href="https://github.com/derekparker/delve">Delve</a> is a better
alternative to GDB when debugging Go programs built with the standard
-tool chain. It understands the Go runtime, data structures, and
+toolchain. It understands the Go runtime, data structures, and
expressions better than GDB. Delve currently supports Linux, OSX,
and Windows on <code>amd64</code>.
For the most up-to-date list of supported platforms, please see
<p>
A recent extension mechanism to GDB allows it to load extension scripts for a
-given binary. The tool chain uses this to extend GDB with a handful of
+given binary. The toolchain uses this to extend GDB with a handful of
commands to inspect internals of the runtime code (such as goroutines) and to
pretty print the built-in map, slice and channel types.
</p>
<h3 id="gc_flag">Command-line flag parsing</h3>
<p>
-In the gc tool chain, the compilers and linkers now use the
+In the gc toolchain, the compilers and linkers now use the
same command-line flag parsing rules as the Go flag package, a departure
from the traditional Unix flag parsing. This may affect scripts that invoke
the tool directly.
<p>
Due to the change of the <a href="#int"><code>int</code></a> to 64 bits and
a new internal <a href="//golang.org/s/go11func">representation of functions</a>,
-the arrangement of function arguments on the stack has changed in the gc tool chain.
+the arrangement of function arguments on the stack has changed in the gc toolchain.
Functions written in assembly will need to be revised at least
to adjust frame pointer offsets.
</p>
The <a href="/cmd/fix/"><code>fix</code></a> command, usually run as
<code>go fix</code>, no longer applies fixes to update code from
before Go 1 to use Go 1 APIs.
-To update pre-Go 1 code to Go 1.1, use a Go 1.0 tool chain
+To update pre-Go 1 code to Go 1.1, use a Go 1.0 toolchain
to convert the code to Go 1.0 first.
</p>
<h3 id="platforms">Additional platforms</h3>
<p>
-The Go 1.1 tool chain adds experimental support for <code>freebsd/arm</code>,
+The Go 1.1 toolchain adds experimental support for <code>freebsd/arm</code>,
<code>netbsd/386</code>, <code>netbsd/amd64</code>, <code>netbsd/arm</code>,
<code>openbsd/386</code> and <code>openbsd/amd64</code> platforms.
</p>
<p>
On the ARM, the toolchain supports "external linking", which
is a step towards being able to build shared libraries with the gc
-tool chain and to provide dynamic linking support for environments
+toolchain and to provide dynamic linking support for environments
in which that is necessary.
</p>
and contains no language changes.
It focuses primarily on implementation work, providing
precise garbage collection,
-a major refactoring of the compiler tool chain that results in
+a major refactoring of the compiler toolchain that results in
faster builds, especially for large projects,
significant performance improvements across the board,
and support for DragonFly BSD, Solaris, Plan 9 and Google's Native Client architecture (NaCl).
<h3 id="gc_flag">Command-line flag parsing</h3>
<p>
-In the gc tool chain, the assemblers now use the
+In the gc toolchain, the assemblers now use the
same command-line flag parsing rules as the Go flag package, a departure
from the traditional Unix flag parsing.
This may affect scripts that invoke the tool directly.
<h2 id="tools">Tools</h2>
<p>
-Finally, the Go tool chain (compilers, linkers, build tools, and so
-on) are under active development and may change behavior. This
+Finally, the Go toolchain (compilers, linkers, build tools, and so
+on) is under active development and may change behavior. This
means, for instance, that scripts that depend on the location and
properties of the tools may be broken by a point release.
</p>
Why is my trivial program such a large binary?</h3>
<p>
-The linker in the <code>gc</code> tool chain
+The linker in the <code>gc</code> toolchain
creates statically-linked binaries by default. All Go binaries therefore include the Go
run-time, along with the run-time type information necessary to support dynamic
type checks, reflection, and even panic-time stack traces.
<div class="detail">
<p>
-There are two official Go compiler tool chains.
+There are two official Go compiler toolchains.
This document focuses on the <code>gc</code> Go
compiler and tools.
For information on how to work on <code>gccgo</code>, a more traditional
<h2 id="go14">Install Go compiler binaries</h2>
<p>
-The Go tool chain is written in Go. To build it, you need a Go compiler installed.
+The Go toolchain is written in Go. To build it, you need a Go compiler installed.
The scripts that do the initial build of the tools look for an existing Go tool
chain in <code>$GOROOT_BOOTSTRAP</code>.
If unset, the default value of <code>GOROOT_BOOTSTRAP</code>
</p>
<p>
-There are many options for the bootstrap tool chain.
+There are many options for the bootstrap toolchain.
After obtaining one, set <code>GOROOT_BOOTSTRAP</code> to the
directory containing the unpacked tree.
For example, <code>$GOROOT_BOOTSTRAP/bin/go</code> should be
-the <code>go</code> command binary for the bootstrap tool chain.
+the <code>go</code> command binary for the bootstrap toolchain.
</p>
<p>
-To use a binary release as a bootstrap tool chain, see
+To use a binary release as a bootstrap toolchain, see
<a href="/dl/">the downloads page</a> or use any other
packaged Go distribution.
</p>
<p>
-To build a bootstrap tool chain from source, use
+To build a bootstrap toolchain from source, use
either the git branch <code>release-branch.go1.4</code> or
<a href="https://dl.google.com/go/go1.4-bootstrap-20171003.tar.gz">go1.4-bootstrap-20171003.tar.gz</a>,
which contains the Go 1.4 source code plus accumulated fixes
to keep the tools running on newer operating systems.
-(Go 1.4 was the last distribution in which the tool chain was written in C.)
+(Go 1.4 was the last distribution in which the toolchain was written in C.)
After unpacking the Go 1.4 source, <code>cd</code> to
the <code>src</code> subdirectory, set <code>CGO_ENABLED=0</code> in
the environment, and run <code>make.bash</code> (or,
</p>
<p>
-To cross-compile a bootstrap tool chain from source, which is
+To cross-compile a bootstrap toolchain from source, which is
necessary on systems Go 1.4 did not target (for
example, <code>linux/ppc64le</code>), install Go on a different system
and run <a href="/src/bootstrap.bash">bootstrap.bash</a>.