Mostly we just care that the test binaries link and start up.
No need to run the full test suites.

Takes 12% off my all.bash run time.

For #10571.

Change-Id: I01af618f3d51deb841ea638424e1389a2df7d746
Reviewed-on: https://go-review.googlesource.com/18086Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>

Takes 3% off my all.bash run time.

For #10571.

Change-Id: I8f00f523d6919e87182d35722a669b0b96b8218b
Reviewed-on: https://go-review.googlesource.com/18087Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

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

I'm tired of having to remember it on every command.
Rebuilding everything is the wrong default.

This CL updates the build script, but the builders may
(or may not) need work, depending on whether they
rebuild using the test command (I doubt it).

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

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

Currently goroutineheader goes through some convolutions to *almost*
print the scan state of a G. However, the code path that would print
the scan state of the G refers to gStatusStrings where it almost
certainly meant to refer to gScanStatusStrings (which is unused), so
it winds up printing the regular status string without the scan state
either way. Furthermore, if the G is in _Gwaiting, we override the
status string and lose where this would indicate the scan state if it
worked.

This commit fixes this so the runtime prints the scan state. However,
rather than using a parallel list of status strings, this simply adds
a conditional print if the scan bit is set. This lets us remove the
string list, prints the scan state even in _Gwaiting, and lets us
strip off the scan bit at the beginning of the function, which
simplifies the rest of it.

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

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

If non-Go code calls sigaltstack before a signal is received, use
sigaltstack to determine the current signal stack and set the gsignal
stack to use it.  This makes the Go runtime more robust in the face of
non-Go code.  We still can't handle a disabled signal stack or a signal
triggered with SA_ONSTACK clear, but we now give clear errors for those
cases.

Fixes #7227.
Update #9896.

Change-Id: Icb1607e01fd6461019b6d77d940e59b3aed4d258
Reviewed-on: https://go-review.googlesource.com/18102
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>

This makes NYCbCrA consistent with YCbCr.

Fixes #13706.

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

s/activitiy/activity

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

s/encrypt/decrypt/

The text is unsafe to cut and paste...

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

Give a link to the wikipedia page describing the mechanism and
explain better how to use the same buffer for input and output.

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

Fixes #13701.

Change-Id: I9825864d23aeba1971cf5f581e1e59ac4c9b87fd
Reviewed-on: https://go-review.googlesource.com/18090Reviewed-by: David Crawshaw <crawshaw@golang.org>

Fixes #13704.

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

This change replaces the existing log format separated by commas and
spaces with space-separated one.

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

Approved by the IETF.

https://datatracker.ietf.org/doc/draft-ietf-httpbis-legally-restricted-status/

Change-Id: I688597bb5f7ef7c7a9be660a4fcd2ef02d9dc9f4
Reviewed-on: https://go-review.googlesource.com/18112Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: David Symonds <dsymonds@golang.org>

Change-Id: Ic3f006f86a86de628e14b107f88a5923ea856a58
Reviewed-on: https://go-review.googlesource.com/18093Reviewed-by: David Symonds <dsymonds@golang.org>

Fixes #13684.

Change-Id: I3977119b6eb1d6b7dc2ea1e7d6656a8f0d421bc1
Reviewed-on: https://go-review.googlesource.com/18060
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>

In general the package net deals IPv4 addresses as IPv6 IPv4-mapped
addresses internally for the dual stack era, when we need to support
various techniques on IPv4/IPv6 translation.

This change makes windows implementation follow the same pattern which
BSD variants and Linux do.

Updates #13544.

Also fixes an unintentionally formatted line by accident by gofmt.

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

CL skips interfaces that are not listed on getmac output.

Fixes #13606

Change-Id: Ic25c9dc95e8eeff4d84b78e99131a4f97020164c
Reviewed-on: https://go-review.googlesource.com/17994Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>

Fixes #13690.

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

Only install signal handlers for synchronous signals that become
run-time panics.  Set the SA_ONSTACK flag for other signal handlers as
needed.

Fixes #13028.
Update #12465.
Update #13034.
Update #13042.

Change-Id: I28375e70641f60630e10f3c86e24b6e4f8a35cc9
Reviewed-on: https://go-review.googlesource.com/17903Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>

Reapply golang.org/cl/17918

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

It turns out that the second argument for sigaction on Darwin has a
different type than the first argument.  The second argument is the user
visible sigaction struct, and does not have the sa_tramp field.

I base this on
  http://www.opensource.apple.com/source/Libc/Libc-1081.1.3/sys/sigaction.c
not to mention actual testing.

While I was at it I removed a useless memclr in setsig, a relic of the C
code.

This CL is Darwin-specific changes.  The tests for this CL are in
https://golang.org/cl/17903 .

Change-Id: I61fe305c72311df6a589b49ad7b6e49b6960ca24
Reviewed-on: https://go-review.googlesource.com/18015Reviewed-by: David Crawshaw <crawshaw@golang.org>

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

Fixes #13681.

Change-Id: I308930f4d9200fbe0f09cd08c38392ca1bb0db67
Reviewed-on: https://go-review.googlesource.com/18044Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Austin Clements <austin@google.com>

Programs that call panic to crash after detecting a serious problem
may wish to use SetTraceback to force printing of all goroutines first.

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

This future-proofs the Chdr64 structure against later versions of ELF
defining this field and declutters the documentation without changing
the layout of the struct.

This structure does not exist in the current release, so this change
is safe.

Change-Id: I239aad7243ddaf063a1f8cd521d8a50b30413281
Reviewed-on: https://go-review.googlesource.com/18028Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>

Fixes #13683.

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

Fixes #13671

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

Copy the same sentence from Transport.TLSNextProto.

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

Fixes #11407.

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

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

Currently, if sigprof determines that the G is in user code (not cgo
or libcall code), it will only traceback the G stack if it can acquire
the stack barrier lock. However, it has no such restriction if the G
is in cgo or libcall code. Because cgo calls count as syscalls, stack
scanning and stack barrier installation can occur during a cgo call,
which means sigprof could attempt to traceback a G in a cgo call while
scanstack is installing stack barriers in that G's stack. As a result,
the following sequence of events can cause the sigprof traceback to
panic with "missed stack barrier":

1. M1: G1 performs a Cgo call (which, on Windows, is any system call,
   which could explain why this is easier to reproduce on Windows).

2. M1: The Cgo call puts G1 into _Gsyscall state.

3. M2: GC starts a scan of G1's stack. It puts G1 in to _Gscansyscall
   and acquires the stack barrier lock.

4. M3: A profiling signal comes in. On Windows this is a global
   (though I don't think this matters), so the runtime stops M1 and
   calls sigprof for G1.

5. M3: sigprof fails to acquire the stack barrier lock (because the
   GC's stack scan holds it).

6. M3: sigprof observes that G1 is in a Cgo call, so it calls
   gentraceback on G1 with its Cgo transition point.

7. M3: gentraceback on G1 grabs the currently empty g.stkbar slice.

8. M2: GC finishes scanning G1's stack and installing stack barriers.

9. M3: gentraceback encounters one of the just-installed stack
   barriers and panics.

This commit fixes this by only allowing cgo tracebacks if sigprof can
acquire the stack barrier lock, just like in the regular user
traceback case.

For good measure, we put the same constraint on libcall tracebacks.
This case is probably already safe because, unlike cgo calls, libcalls
leave the G in _Grunning and prevent reaching a safe point, so
scanstack cannot run during a libcall. However, this also means that
sigprof will always acquire the stack barrier lock without contention,
so there's no cost to adding this constraint to libcall tracebacks.

Fixes #12528. For 1.5.3 (will require some backporting).

Change-Id: Ia5a4b8e3d66b23b02ffcd54c6315c81055c0cec2
Reviewed-on: https://go-review.googlesource.com/18023
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

Currently, setNextBarrierPC manipulates the stack barriers without
acquiring the stack barrier lock. This is mostly okay because
setNextBarrierPC also runs synchronously on the G and prevents safe
points, but this doesn't prevent a sigprof from occurring during a
setNextBarrierPC and performing a traceback.

Given that setNextBarrierPC simply sets one entry in the stack barrier
array, this is almost certainly safe in reality. However, given that
this depends on a subtle argument, which may not hold in the future,
and that setNextBarrierPC almost never happens, making it nowhere near
performance-critical, we can simply acquire the stack barrier lock and
be sure that the synchronization will work.

Updates #12528. For 1.5.3.

Change-Id: Ife696e10d969f190157eb1cbe762a2de2ebce079
Reviewed-on: https://go-review.googlesource.com/18022
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>

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

Update #12416.

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

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

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

Change-Id: If2b30ab412d6799c8be01eb007462d6b58660ece
Reviewed-on: https://go-review.googlesource.com/18014Reviewed-by: Chris Broadfoot <cbro@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>