This change implements the requirement of
old Go to build new Go on Plan 9. Also fix
the build of the new cmd/dist written in Go.

This is similar to the make.bash change in
CL 2470, but applied to make.rc for Plan 9.

Change-Id: Ifd9a3bd8658e2cee6f92b4c7f29ce86ee2a93c53
Reviewed-on: https://go-review.googlesource.com/2662Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

These are corresponding Windows changes for the GOROOT_BOOTSTRAP and
dist changes in https://golang.org/cl/2470

Change-Id: I21da2d63a60d8ae278ade9bb71ae0c314a2cf9b5
Reviewed-on: https://go-review.googlesource.com/2674Reviewed-by: Alex Brainman <alex.brainman@gmail.com>

* Use WORD declaration so 5a can't rewrite the instruction or complain
  about forms it doesn't know about.
* Add the interpunct to function declaration.

Change-Id: I8494548db21b3ea52f0e1e0e547d9ead8b93dfd1
Reviewed-on: https://go-review.googlesource.com/2682Reviewed-by: Minux Ma <minux@golang.org>

This CL introduces the bootstrap requirement that in order to
build the current release (or development version) of Go, you
need an older Go release (1.4 or newer) already installed.
This requirement is the whole point of this CL.

To enforce the requirement, convert cmd/dist from C to Go.

With this bootstrapping out of the way, we can move on to
replacing other, larger C programs like the Go compiler,
the assemblers, and the linker.

See golang.org/s/go15bootstrap for details.

Change-Id: I53fd08ddacf3df9fae94fe2c986dba427ee4a21d
Reviewed-on: https://go-review.googlesource.com/2470Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

This CL makes the next one have nice cross-file diffs.

Change-Id: I9ce897dc505dea9923be4e823bae31f4f7fa2ee2
Reviewed-on: https://go-review.googlesource.com/2471Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fold in some startup randomness to make the hash vary across
different runs.  This helps prevent attackers from choosing
keys that all map to the same bucket.

Also, reorganize the hash a bit.  Move the *m1 multiply to after
the xor of the current hash and the message.  For hash quality
it doesn't really matter, but for DDOS resistance it helps a lot
(any processing done to the message before it is merged with the
random seed is useless, as it is easily inverted by an attacker).

Update #9365

Change-Id: Ib19968168e1bbc541d1d28be2701bb83e53f1e24
Reviewed-on: https://go-review.googlesource.com/2344Reviewed-by: Ian Lance Taylor <iant@golang.org>

The gc toolchain no longer includes a C compiler, so mentions of "6c"
can be removed or replaced by 6g as appropriate.  Similarly, some cgo
functions that previously generated C source output no longer need to.

Change-Id: I1ae6b02630cff9eaadeae6f3176c0c7824e8fbe5
Reviewed-on: https://go-review.googlesource.com/2391Reviewed-by: Ian Lance Taylor <iant@golang.org>

Change-Id: I315b338968cb1d9298664d181de44a691b325bb8
Reviewed-on: https://go-review.googlesource.com/2450Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Reader.Discard is the complement to Peek. It discards the next n bytes
of input.

We already have Reader.Buffered to see how many bytes of data are
sitting available in memory, and Reader.Peek to get that that buffer
directly. But once you're done with the Peek'd data, you can't get rid
of it, other than Reading it.
Both Read and io.CopyN(ioutil.Discard, bufReader, N) are relatively
slow. People instead resort to multiple blind ReadByte calls, just to
advance the internal b.r variable.

I've wanted this previously, several people have asked for it in the
past on golang-nuts/dev, and somebody just asked me for it again in a
private email. There are a few places in the standard library we'd use
it too.

Change-Id: I85dfad47704a58bd42f6867adbc9e4e1792bc3b0
Reviewed-on: https://go-review.googlesource.com/2260Reviewed-by: Russ Cox <rsc@golang.org>

This CL only fixes the build, there are two failing tests:
RaceMapBigValAccess1 and RaceMapBigValAccess2
in runtime/race tests. I haven't investigated why yet.

Updates #9516.

Change-Id: If5bd2f0bee1ee45b1977990ab71e2917aada505f
Reviewed-on: https://go-review.googlesource.com/2401Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

Use direct binary insertion instead of recursive calls to symMerge
when one of the blocks has only one element.

benchmark                   old ns/op      new ns/op      delta
BenchmarkStableString1K     421999         397629         -5.77%
BenchmarkStableInt1K        123422         120592         -2.29%
BenchmarkStableInt64K       9629094        9620200        -0.09%
BenchmarkStable1e2          123089         120209         -2.34%
BenchmarkStable1e4          39505228       36870029       -6.67%
BenchmarkStable1e6          8196612367     7630840157     -6.90%

Change-Id: I49905a909e8595cfa05920ccf9aa00a8f3036110
Reviewed-on: https://go-review.googlesource.com/2219Reviewed-by: Robert Griesemer <gri@golang.org>

sysReserve doesn't actually reserve the full amount requested on
64-bit systems, because of problems with ulimit. Instead it checks
that it can get the first 64 kB and assumes it can grab the rest as
needed. This doesn't work well with the "let the kernel pick an address"
mode, so don't do that. Pick a high address instead.

Change-Id: I4de143a0e6fdeb467fa6ecf63dcd0c1c1618a31c
Reviewed-on: https://go-review.googlesource.com/2345Reviewed-by: Rick Hudson <rlh@golang.org>

The line 'mp.schedlink = mnext' has an implicit write barrier call,
which needs a valid g. Move it above the setg(nil).

Change-Id: If3e86c948e856e10032ad89f038bf569659300e0
Reviewed-on: https://go-review.googlesource.com/2347Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

This test is doing pointer graph manipulation from C, and we
cannot support that with concurrent GC. The wbshadow mode
correctly diagnoses missing write barriers.

Disable the test in that mode for now. There is a bigger issue
behind it, namely SWIG, but for now we are focused on making
all.bash pass with wbshadow enabled.

Change-Id: I55891596d4c763e39b74082191d4a5fac7161642
Reviewed-on: https://go-review.googlesource.com/2346Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>

It did tons of write syscalls before:
    https://www.youtube.com/watch?v=t60fhjAqBdw

This is the worst offender. It's not worth fixing all the cases of two
consecutive prints.

Change-Id: I95860ef6a844d89b149528195182b191aad8731b
Reviewed-on: https://go-review.googlesource.com/2371Reviewed-by: Rob Pike <r@golang.org>

There are two methods by which TLS clients signal the renegotiation
extension: either a special cipher suite value or a TLS extension.

It appears that I left debugging code in when I landed support for the
extension because there's a "+ 1" in the switch statement that shouldn't
be there.

The effect of this is very small, but it will break Firefox if
security.ssl.require_safe_negotiation is enabled in about:config.
(Although almost nobody does this.)

This change fixes the original bug and adds a test. Sadly the test is a
little complex because there's no OpenSSL s_client option that mirrors
that behaviour of require_safe_negotiation.

Change-Id: Ia6925c7d9bbc0713e7104228a57d2d61d537c07a
Reviewed-on: https://go-review.googlesource.com/1900Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

SignPSS is documented as allowing opts to be nil, but actually
crashes in that case. This change fixes that.

Change-Id: Ic48ff5f698c010a336e2bf720e0f44be1aecafa0
Reviewed-on: https://go-review.googlesource.com/2330Reviewed-by: Minux Ma <minux@golang.org>

First, call clearcheckmarks immediately after changing checkmark,
so that there is less time when the checkmark flag and the bitmap
are inconsistent. The tiny gap between the two lines is fine, because
the world is stopped. Before, the gap was much larger and included
such code as "go bgsweep()", which allocated.

Second, modify gcphase only when the world is stopped.
As written, gcscan_m was changing gcphase from 0 to GCscan
and back to 0 while other goroutines were running.
Another goroutine running at the same time might decide to
sleep, see GCscan, call gcphasework, and start "helping" by
scanning its stack. That's fine, except that if gcphase flips back
to 0 as the goroutine calls scanblock, it will start draining the
work buffers prematurely.

Both of these were found wbshadow=2 (and a lot of hard work).
Eventually that will run automatically, but right now it still
doesn't quite work for all.bash, due to mmap conflicts with
pthread-created threads.

Change-Id: I99aa8210cff9c6e7d0a1b62c75be32a23321897b
Reviewed-on: https://go-review.googlesource.com/2340Reviewed-by: Rick Hudson <rlh@golang.org>

Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.

Change-Id: I5624b509a36650bce6834cf394b9da163abbf8c0
Reviewed-on: https://go-review.googlesource.com/2310Reviewed-by: Rick Hudson <rlh@golang.org>

Fixes #9121

Change-Id: Id6ca9f259260310c4c6cbdabbc8f2fead8414e6a
Reviewed-on: https://go-review.googlesource.com/2202Reviewed-by: Minux Ma <minux@golang.org>

Change-Id: Ia18b8411bebc47ea71ac1acd9ff9dc570ec15dea
Reviewed-on: https://go-review.googlesource.com/2341Reviewed-by: Dave Cheney <dave@cheney.net>

Use typedmemmove, typedslicecopy, and adjust reflect.call
to execute the necessary write barriers.

Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.

Change-Id: Iec5b5b0c1be5589295e28e5228e37f1a92e07742
Reviewed-on: https://go-review.googlesource.com/2312Reviewed-by: Keith Randall <khr@golang.org>

These depend on storing arbitrary integer values using
pointer atomics, and we can't support that anymore.

Change-Id: I8cadd6d462c3eebdbe7078f43fe7c779fa8f52b3
Reviewed-on: https://go-review.googlesource.com/2311Reviewed-by: Rick Hudson <rlh@golang.org>

A side effect of this change is that when assertI2T writes to the
memory for the T being extracted, it can use typedmemmove
for write barriers.

There are other ways we could have done this, but this one
finishes a TODO in package runtime.

Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.

Change-Id: Icbc8aabfd8a9b1f00be2e421af0e3b29fa54d01e
Reviewed-on: https://go-review.googlesource.com/2279Reviewed-by: Keith Randall <khr@golang.org>

Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.

Change-Id: I1320d5340a9e421c779f24f3b170e33974e56e4f
Reviewed-on: https://go-review.googlesource.com/2278Reviewed-by: Rick Hudson <rlh@golang.org>

Found with GODEBUG=wbshadow=2 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.

Change-Id: Iea83d693480c2f3008b4e80d55821acff65970a6
Reviewed-on: https://go-review.googlesource.com/2277Reviewed-by: Keith Randall <khr@golang.org>

Preparation for replacing many memmove calls in runtime
with typedmemmove, which is a clearer description of what
the routine is doing.

For the same reason, rename writebarriercopy to typedslicecopy.

Change-Id: I6f23bef2c2215509fefba175b16908f76dc7538c
Reviewed-on: https://go-review.googlesource.com/2276Reviewed-by: Rick Hudson <rlh@golang.org>

Add write barrier to atomic operations manipulating pointers.

In general an atomic write of a pointer word may indicate racy accesses,
so there is no strictly safe way to attempt to keep the shadow copy
in sync with the real one. Instead, mark the shadow copy as not used.

Redirect sync/atomic pointer routines back to the runtime ones,
so that there is only one copy of the write barrier and shadow logic.
In time we might consider doing this for most of the sync/atomic
functions, but for now only the pointer routines need that treatment.

Found with GODEBUG=wbshadow=1 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.

Change-Id: I852936b9a111a6cb9079cfaf6bd78b43016c0242
Reviewed-on: https://go-review.googlesource.com/2066Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

The Gobuf.g goroutine pointer is almost always updated by assembly code.
In one of the few places it is updated by Go code - func save - it must be
treated as a uintptr to avoid a write barrier being emitted at a bad time.
Instead of figuring out how to emit the write barriers missing in the
assembly manipulation, change the type of the field to uintptr, so that
it does not require write barriers at all.

Goroutine structs are published in the allg list and never freed.
That will keep the goroutine structs from being collected.
There is never a time that Gobuf.g's contain the only references
to a goroutine: the publishing of the goroutine in allg comes first.

Goroutine pointers are also kept in non-GC-visible places like TLS,
so I can't see them ever moving. If we did want to start moving data
in the GC, we'd need to allocate the goroutine structs from an
alternate arena. This CL doesn't make that problem any worse.

Found with GODEBUG=wbshadow=1 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.

Change-Id: I85f91312ec3e0ef69ead0fff1a560b0cfb095e1a
Reviewed-on: https://go-review.googlesource.com/2065Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Found with GODEBUG=wbshadow=1 mode.
Eventually that will run automatically, but right now
it still detects other missing write barriers.

Change-Id: Ic8624401d7c8225a935f719f96f2675c6f5c0d7c
Reviewed-on: https://go-review.googlesource.com/2064Reviewed-by: Rick Hudson <rlh@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

This is the detection code. It works well enough that I know of
a handful of missing write barriers. However, those are subtle
enough that I'll address them in separate followup CLs.

GODEBUG=wbshadow=1 checks for a write that bypassed the
write barrier at the next write barrier of the same word.
If a bug can be detected in this mode it is typically easy to
understand, since the crash says quite clearly what kind of
word has missed a write barrier.

GODEBUG=wbshadow=2 adds a check of the write barrier
shadow copy during garbage collection. Bugs detected at
garbage collection can be difficult to understand, because
there is no context for what the found word means.
Typically you have to reproduce the problem with allocfreetrace=1
in order to understand the type of the badly updated word.

Change-Id: If863837308e7c50d96b5bdc7d65af4969bf53a6e
Reviewed-on: https://go-review.googlesource.com/2061Reviewed-by: Austin Clements <austin@google.com>

When constants were declared using unexported constants,
the type information was lost when those constants were filtered out.
This CL propagates the type information of unexported constants
so that it is available for display.

This is a follow-up to CL 144110044, which fixed this problem
specifically for _ constants.

Updates #5397.

Change-Id: I3f0c767a4007d88169a5634ab2870deea4e6a740
Reviewed-on: https://go-review.googlesource.com/2091Reviewed-by: Robert Griesemer <gri@golang.org>

Fixes #9509

Change-Id: I3b86745d38e09093fe2f4b918d774bd6608727d7
Reviewed-on: https://go-review.googlesource.com/2313Reviewed-by: Robert Griesemer <gri@golang.org>

Noticed while investigating the speed of the runtime tests, as part
of debugging while Plan 9's runtime tests are timing out on GCE.

Change-Id: I95f5a3d967a0b45ec1ebf10067e193f51db84e26
Reviewed-on: https://go-review.googlesource.com/2283Reviewed-by: Ian Lance Taylor <iant@golang.org>

The existing go code document did not link to the GOPATH documentation.
This will link to it, in hopes of making it more discoverable.

Change-Id: Ie4ded2fdce08f412e4acbcc93acdd76f5791b84a
Reviewed-on: https://go-review.googlesource.com/2265Reviewed-by: Andrew Gerrand <adg@golang.org>

Change-Id: Ic6bc4af7bcc89b2881b2b9e7290aeb6fd54804e2
Reviewed-on: https://go-review.googlesource.com/2239Reviewed-by: Ian Lance Taylor <iant@golang.org>

This reverts commit ab0535ae.

I think it will remain useful to distinguish code that must
run on a system stack from code that can run on either stack,
even if that distinction is no
longer based on the implementation language.

That is, I expect to add a //go:systemstack comment that,
in terms of the old implementation, tells the compiler,
to pretend this function was written in C.

Change-Id: I33d2ebb2f99ae12496484c6ec8ed07233d693275
Reviewed-on: https://go-review.googlesource.com/2275Reviewed-by: Russ Cox <rsc@golang.org>

Fixes #9504.

Change-Id: I148f407ace3d1b4db3f19fbb8561d1ee6c4c13b3
Reviewed-on: https://go-review.googlesource.com/2273Reviewed-by: Rob Pike <r@golang.org>

Change-Id: Ida3b431a06527f6cd604ab4af5ce517959c8619b
Reviewed-on: https://go-review.googlesource.com/2306Reviewed-by: Dave Cheney <dave@cheney.net>

Change-Id: Ie47c6460c1749aef3cf6d7c6ba44d43305d7ca7b
Reviewed-on: https://go-review.googlesource.com/2305Reviewed-by: Minux Ma <minux@golang.org>